More on work hours...

Kinda leading on from something Dabs wrote in the comments on the post about email, it reminded me of an excellent book by Steve Maguire, 'Debugging the Development Process' (Microsoft Press). In it are great guideline for running a project well... I found a great summary here...

http://www.fountain.btinternet.co.uk/rapiddev/debugging.html

...and 're-printed' it here.

1. Be clear about what you are trying to do. Don't try to do too much, understand what is important and seek to achieve it.

2. Ensure programmer have the time to code - all the distractions of reports, meetings, reviews should be cut back so they can spend most of their time programming. The task of the 'lead' is to free the paths of the programmers.

3. Fix bugs as you go. Always put fixing bugs first - certainly don't leave fixing bugs in the project until last. Programmers shouldn't go onto their next task until they have fixed the bugs in their previous task. Fix bugs now.

4. When a programmer finds a bug, ask how it could have been avoided. What could be done to stop a similar bug going in again?

5. Ensure programmers "batch up" admin tasks such as e-mail to keep a clean stretch of the day for solid programming.

6. Learn to say 'no'. It is best to tell people you can't do something than to fail to deliver.

7. Always understand why somebody wants something - don't just implement something without understanding the background. There may be a better way to do it, or the solution may already be available.

8. Don't implement features because your boss tells you to, or because they are technically interesting or cool - only implement features that are strategic. Be very firm about what goes into a product - cut everything you don't need to spend time on, to make time for what you need to do.

9. Also beware of "rewrites" - rewriting C in C++ or adding headers or comments or using a new naming convention. This will all take time. If you do anything, say do it in line with development - spend an hour a week adding comments for example.

10. Find out why someone wants a feature - what is their motivation?

11. Question everything you do - don't just follow a practise for the sake of it. Look at reports and meetings - are they really necessary? Programmers are often distracted from programming due to too many reports and meetings. No programmer enjoys a day spent doing reports or sitting in meetings, so not only are you potentially wasting time that could be spent programming, you are lowering morale.

12. The exception to this is postmortem meetings. However finding out what went wrong must have an effective attack plan, who will do what and when. It is no good just saying what went wrong, it is not even any good saying what should be done about it. It is only when what should be done is assigned to people with time allocated and deadlines to do it in that something will happen.

13. Unrealistic schedules not only create logistical problems for the company due to project dependencies, they lower programmer morale and make the liklihood of "quick and dirty" programming go up. Any project end date is a best case estimate made in good faith on the information available - it is not a promise to hit that date regardless. Telling programmers they are behind with their schedule and continually emphasising the project end date will only lower morale and cause quality problems. The only way to address schedule problems is to extend the end date and/or cut functionality. For this reason do the most important features first, so if anything gets cut it is less important. Also create milestones within a project to be aware of how on track it is - typically every two months. Adding resource to a project is typically not an option - resources take time to get up to speed and production is not directly related to team size (four programmers don't produce twice as much as two).

14. Make sure programmers are constantly learning new skills. It keeps them sharp and adds value to the team, and makes it less likely a valued member of staff will leave for something more interesting.

15. Don't set goals at reviews, set goals during the year as work that makes sense to use new skills comes up. Simply document new skills and goals achieved at reviews.

16. Aim for each programmer to learn a new skill every two months.

17. If as a lead you see something wrong or that could be improved do something about it immediately. Don't wait for the next review.

18. Programmers must work as hard as possible to remove bugs from code. When code is written, programmers must always at least step through it to check it is working. Other tasks in debugging might include writing tests and test scenarios. When considering spending time on testing, beware of the programmer who objects on the grounds that it will take too much time or would be too difficult. Always ask (a) does adding the debug code make sense, (b) does it fulfill the goals and priorities of the project, (c) is it important enough to justify the time?

19. Encourage ideas and suggestions to prevent an environment of can't do. Listen to people raise possible problems even if they don't have the solution.

20. Beware of the "it's good enough for users" attitude - users have high expectations. Also never release a low-quality feature, even if you think something is better than nothing. This is never the case - if it isn't good quality, don't release it. If it is really important, delay the ship date.

21. Beware of duplication - two programmers doing the same thing. Work for re-use where possible.

22. Think about the whole product, some developers and leads adopt a "blind spot" to weak areas of the product, they focus on the goo bits and put their head in the sand about the weak areas. Remember users want the whole product to work well.

23. If programmers are working long hours something is wrong. It is like sailing a ship with a leak - if the sailors are constantly bailing out water they are working hard, but to what end? It would be more effective to block the leak. Similarly look at why people are working long hours. Are the schedules unrealistic? Are the programmers unable to effectively manage their time? Ask a programmer who works long hours to write down what they do all day. As a suggestion, work all morning on the project then after lunch look at e-mail for the first time, then work on the project again, half-way through the afternoon take more interruptions, then work on the project, and finally before you go home check e-mail and take interruptions for the last time. Only work long hours for a short aim - a show or release date - not as a way of life.

Still with me??

Dispite being written about code, you can pretty much apply all that to any kind of project. It's about setting realistic goals, working in a structured way, and knowing when to say NO. That's pretty much how I work now.

I've learnt the hard way that killing yourself for the sake of a project just doesn't work. Sure, all projects have phases where extra hours are required, but if they last more than 2 days, your project is in trouble IMHO.

There's another excellent article on Gamastura about 'crunch times' that is worth a read. You might need to register though.

http://www.gamasutra.com/features/20040123/fristrom_pfv.htm

Anyway - enough of all that.... go buy The Faders single!

Nic.

posted by Nic @ 5:21 PM 2 comments