The .NET Software Process

- Keys To Success

(Author's note: As I complete a new software project I usually like to reflect:  What worked best?  What did I learn that I can apply to future projects and clients?  There's a common-sense approach to the software development process followed by most of the successful organizations I see.  The article below  is from Software Development Times.   It exemplifies a practical mindset to software.)

21 Rules of Thumb for Delivering Great Products on Time

Delivering great products on time is a difficult but not impossible task. Elements you think would count the most count for very little. Development methodology, process, technical prowess, excellence of tools and depth of project management skills all influence the outcome of a software development project; but nothing indicates success as much as the individual's ability to focus on a few critical and conceptually simple things. These things can be expressed as rules of thumb.

1. Don't know what you don't know.  It is essential not to profess to know, or seem to know, or accept that someone else knows, that which is unknown. Almost without exception, the things that end up coming back to haunt you are things you pretended to understand but didn't early on.

2. Get to a known state and stay there. The function of QA is to know (and articulate) the quality of the product at all times in the development cycle.

3. Remember the triangle. There are fundamentally three things that you are working with as a member of a development team: resources (people, money and things that cost money), product features (including the quality of their implementation) and time (primarily as expressed in a schedule). Changing one has an impact on at least one other axis, usually two.

4. Don't go dark. Some features have long development lead times-months or even years. Yet slips usually happen a little bit every day, and must be compensated for a little every day. This means that the granularity of individual tasks must be such that deliverables are made at intervals sufficiently small that slips will surface frequently enough to be compensated for.

5. Use zero defect milestones. Organize the project around the concept a reaching milestones with zero defects. ZD does not mean that the product does not have bugs, or missing functionality. It means that the product achieves the quality level that had been set for that milestone.

6. Beware of a guy in a room. This is really just a special case of "Don't go dark." Specialist developers who lock themselves away in a room, going dark for long stretches, are anathema to delivering great software on time.

7. Never trade a bad date for an equally bad date. Generally, you know you're going to be late before you know when you're going to be done.

8. When slipping, don't fall. Slipping is what happens when information that was unknown becomes less unknown. Though slipping is widely perceived to be a "bad" thing, it is the symptom of a good thing, as a fever is the sign of the body's immune system at work.

9. Low tech is good. A smaller effort is almost always more desirable than a larger one. Delivering great software on time requires that we value an understood solution much more highly than one fraught with unknowns. Keep in mind that customers would almost always rather see progress than promises.

10. Design time at design time. The product will ship when the design can be shown to be implemented. Developers and their managers often ignore the exigencies of time when creating a design. Instead, they should consider the implementation time as a critical design element.

11. If you build it, it will ship. Conversely, if you don't, it won't. The product should be built every day, along with all setup scripts and online help, in a public place, where QA can conduct appropriate assessment of daily status, and the entire team can observe progress or its lack.

12. Portability is for canoes. And system software. Even discounting the added development burden, with the addition of each additional platform the job of QA increases substantially.

13. Enrapture the customers. Most software is a renewal business. Customers buy multiple releases over a relatively long period of time. As a consequence, the market has a deep understanding of your software and its flaws, and your organization and its flaws.

14. Remember one thing: unity. Unity is the master principle of great software. Each element in the product is necessary to the value of the whole, and all necessary elements are there. Since everything you need is there, you aren't tempted to go beyond the present experience, and since nothing is there that isn't required, your absorption into the world of the product will not be disturbed.

15. State your theme. Theme is the dominant idea that constitutes the basis of the design. All of the values of the product must stem from the theme.

16. Vary it. Variation is the theme restated and elaborated in slightly altered and embroidered ways. Variation is the means by which we intensify the user's comprehension and appreciation of our theme, and leverage his/her growing consciousness in new ways.

17. Balance it. Allocate appropriate emphasis among the various elements of the product. If a key component supporting the theme, encountered every time the thematic function is enacted, is weak, the theme is weakly stated and the product will be justly criticized.

18. Evolve it. Evolution is when earlier parts determine later parts. Lessons learned in one part of the product apply to the others. Things progress in a way that is pleasing. Outcomes, if not predictable, are satisfying because the product foreshadows them in countless ways.

19. Your product should be a hierarchy. Hierarchy is when the elements of the product gain attention in proportion to their importance.

20. Establish a shared vision. It seems absurd to even have to state this, yet it is perhaps the most difficult thing of all to achieve. Everybody on the team must know what they are trying to achieve, what the finished product will look like, what the basis of the product strategy is, and when they must deliver it in order for it to have its intended effect. Contradictory visions must be resolved and unified. Harmonious purpose must be achieved, or greatness is out of the question and even delivering becomes infinitely more complicated.

21. Get the team into ship mode. There is a moment on every development project when it is ideal for a team to enter ship mode, which is basically a succession of daily milestones climaxing with the product's shipment. Ship mode is a high-performance period characterized by efficiency and determination. It is a period of flow.

Read the full article  

I welcome your comments.