CS1666 Productivity Tools

1. CS1666 Productivity Tools Feb 24th 2011, Liz Marai Joel Spolsky, “Joel on Software” Did you know? 2004 study: 1/3 of all sw developers use no methodology at all 1995 CHAOS report on sw projects: 16% success, 31% failures, 53% (severely) challenged

2. Joel Spolsky • sw engineer • Project Manager on the Microsoft Excel team 1991-1994 • founded Fog Creek Sw in 2000 • launched “Joel on Software” blog • including his famous “Joel Test” • quote: “Beware of Methodologies” cs1666 Liz Marai -- Productivity

3. “Beware of Big-M Methodologies” • “Beware of Methodologies. They are a great way to bring everyone up to a dismal but passable level of performance, but at the same time they are aggravating to the more talented people who chafe at the restrictions that are placed on them. It’s pretty obvious to me that a talented chef is not going to be happy making burgers at McDonald’s, precisely because of McDonald’s rules”. • the Joel Test: a quick and dirty set of 12 principles, based on his own experience and “collective wisdom”, to judge whether a development organization has its act together. cs1666 Liz Marai -- Productivity

4. 1 • Do you use source control? Revision control, also known as version control or source control is the management of changes to files. A team of people may change the same files. Changes are usually identified by a number or letter code, termed the "revision number", "revision level", or simply "revision". Each revision is associated with a timestamp and the person making the change. Revisions can be compared, restored, and merged. For your project: code.google.com, sourceforge.net, subversion.apache.org, bitbucket.org, github.com Joe and I need to have full access to your repository. cs1666 Liz Marai -- Productivity

5. 2 • Can you make build in one step? ‘make’ is a utility that automatically builds executable programs and libraries from source code by reading files called makefiles which specify how to derive the target program. Make can decide where to start through topological sorting. Though integrated development environments and language-specific compiler features can also be used to manage the build process in modern systems, make remains widely used, especially in Unix. cs1666 Liz Marai -- Productivity

6. 3 • Do you make daily builds? cs1666 Liz Marai -- Productivity

7. 4 • Do you have a bug database? For your project: www.fogcreek.com/fogbugz/pricing.html; free for 45 days, if you time it right after Spring Break it shd last for the rest of the term. Student teams of 1 or 2 can get it for free, forever -- read all the way through the page www.bestpractical.com/rt/ this is what our tech staff uses for bug tracking; the downside is you need to run SQL as well, I believe. cs1666 Liz Marai -- Productivity

8. 5 • Do you fix bugs before writing new code? cs1666 Liz Marai -- Productivity

9. 6 • Do you have an up-to-date schedule? For your project: use an online calendar with deadlines and who’s responsible for what (calendar.google.com) cs1666 Liz Marai -- Productivity

10. 7 • Do you have a spec? For your project: roughly, that’s your Game Design Document. cs1666 Liz Marai -- Productivity

11. 8 • Do programmers have quiet working conditions? cs1666 Liz Marai -- Productivity

12. 9 • Do you use the best tools money can buy? cs1666 Liz Marai -- Productivity

13. 10 • Do you have testers? cs1666 Liz Marai -- Productivity

14. 11 • Do new candidates write code during their interview? cs1666 Liz Marai -- Productivity

15. 12 • Do you do hallway usability testing? cs1666 Liz Marai -- Productivity

16. Spolsky’s Scoring • a score of 12 is perfect • 11 is tolerable • 10 or lower means you’ve got serious problems • “the truth is that most sw organizations are running with a score of 2 or 3, and they need serious help” cs1666 Liz Marai -- Productivity

17. In cs1666, Aim for >=7 Mandatory • source control (google code, sourceforge, svn etc) • bug tracking (wiki, text file, database) • up-to-date schedule (group calendar) • have a spec (some form of a design document) • quiet conditions • testers • usability testing • integrate your code early and build often cs1666 Liz Marai -- Productivity

18. Sending Email • One topic per email. ALWAYS. Not two, not three. One topic per email. • OK to resend in 48 hours if no reply. • If you want things done, email TODO items to one person. ALWAYS. Not to a group. To one specific person. • Sign your emails. cs1666 Liz Marai -- Productivity

19. Measuring Performance (Rosenberg reading post-mortem) OKR -- Objectives and Key Results • Every quarter every programmer sets goals (called OKRs at Google) and a timeline, for the next 90 days (e.g., delivering, improving or growing something by x% by MM/DD), and then measures performance at the end of the quarter. • “I submitted my Q1 OKRs with what I thought were aggressive yet achievable goals. Not good enough. My manager explained that we needed to [be more aggressive]” (Don Dodge, at Google) • Set quarterly goals, and then figure out how to achieve them. • Measure progress every quarter via self-, peer-, and manager- evaluations • Reward outstanding achievement. cs1666 Liz Marai -- Productivity