75 suggestions on how to write software effectively

1. Does your project team use source code management tools?

should be used. VSS, CVS, PVCS, ClearCase, Ccc/harvest, Firefly are all available. My choice is VSS.

2. Does your project team use the defect management system?

should be used. ClearQuest is too complicated, my recommendation is bugzilla.

3. Are your test groups still using Word to write test cases?

Do not write test cases in Word. You should use a dedicated system, either test Manager or your own small web site for developing a asp.net. The main purpose is track and browse.

4. Did your project team set up a portal site?

To have a portal site for contact Info, baselined Schedule, news, and so on. Recommend SharePoint Portal Server 2003来 implementation in 15 minutes. You cannot afford SPS 2003 with WSS (Windows Sharepoint Service).

5. Did your project team use the best tools you could buy?

You should work with as good a tool as you can. For example, you should use vs.net instead of Notepad to write C #. Writing programs in Notepad is mostly just a show of ostentation. But you also have to consider the funding, so that is "you can buy the best."

6. Do your programmers work in a quiet environment?

A quiet environment is needed. This is extremely important, and to ensure that each person's space is greater than a certain area.

7. Do all your employees have a phone?

We need a phone call per person. And the phone is best with a message function. Of course, such a set of message phone system overhead. But at least a phone call to have, do not make often people stand up shouting: "So-and-so a phone." This practice is strongly condemned in the human piece.

8. Do each of you know who should be looking for a problem?

Should know. Any feature should have at least one owner, of course, owner can continue to dispatch to others.

9. Have you ever met someone who said, "I thought ..."?

To destroy "I thought." Never assume anything.

10. Are all the people in your project group sitting together?

Need. I am against virtual team, and also against Dev in the United States, test in China this way of development. It's better to sit together and have a lot of benefits.

11. Does your schedule reflect the latest developments?

should reflect. However, a baseline approach should be used to manage the schedule: maintain a stable schedule and maintain a new change. The baseline method should also be used in other spec. Baseline is an important tool in change management.

12. Is your workload first estimated by everyone?

We should let everyone estimate for themselves. You need to bottom-up estimate the workload, rather than assigning it from the top down. Unless there are other reasons, such as the fixed duration of political tasks.

13. Did your developers work overtime from the start of the project?

Don't do that. Don't get tired from the start. Working overtime from the start of a project can only indicate that the project is not progressing properly. Of course, some software outsourcing to Japan must work overtime every day, that is the category of exploitation.

14. Is the buffer time in your project plan added behind each small task?

No. The Buffer time is easily consumed by the time it is added behind each small task. Buffer time to add the whole paragraph to the front of a milestone or checkpoint.

15. It is worthwhile to spend some more time, from 95% to 100% well worth it.

Especially when the project late Mashi, should insist. This will make a qualitative difference to the product.