The .NET Software Process
- Keys To Success
by M. Wonacott, Principal Consultant/Developer, Vizzit Corporation
About the author...
(Author's note: As I complete a new software project I usually like
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
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
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
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.