21 Reglas Para Entregar Software A Tiempo

21 Rules of Thumb
for
Shipping Great Software on Time



Shipping great software 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 indicatessuccess as much as the manager’s ability to focus on a few critical and conceptually simple things. These things can be expressed as rules of thumb.

I enumerate twenty-one of these rules of thumb. Pick a handful (or so), apply them, and your project will be more likely to succeed. I lump them into three groups: “Shipping,” “Great Software,” “On Time”. Duh. I cover them in a different order,because the concepts build a bit.


On Time


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. At virtually every stage of even the most successfulsoftware projects, there are large numbers of very important things that are unknown. It is acceptable, even mandatory, to clearly articulate your ignorance, so that no one misunderstands the corporate state of unknowingness. If you do not disseminate this “lucid ignorance,” disaster will surely befall you.

Human nature is such that we dislike not knowing things that are important to ourwell being. Since there is so much we don’t know in a software project, the nearly universal tendency among developers and their managers is to gloss over or even deny altogether the extent of their ignorance. You should reward and treasure those who consistently make themselves aware of the list of relevant things that are currently unknown. It requires mental and psychological strength toresist the normal human cravings for certainty and order. It especially difficult to believe in uncertainty when things have a veneer of orderliness, which is often the case. Pseudo-order is a maladapted defense against uncertainty.

The organization surrounding you will undoubtedly abhor uncertainty, would infinitely prefer pseudo-order and will make countless attempts to magically convertyour ignorance to knowledge. Your job is to make uncertainty an unshakable fact, and to coerce the reshaping of the surrounding organization to cope with the uncertain situation. The organization must learn to thrive in an uncertain environment for its own well being.

You should expend a great deal of effort making sure that all the people on the project are aware of their ignorance ratherthan naively converting it to falsehoods. Bear down on them until they realize they haven’t comprehensively assessed the unknowns. In the successful project, this is much easier in the early stages, or during times of change. This is no time for niceties. People ultimately prefer success even if disillusionment is a prerequisite.


2. Get to a known state and stay there.

The function ofQA is to know (and articulate) the quality of the product at all times in the development cycle. This should be achieved by abbreviated, repeatable tests conducted daily, and full product sweeps conducted weekly or biweekly.

It is not properly the job of QA to determine when a product is ready to ship; rather, the moment of shipworthiness in a product development cycle is evident to everyoneinvolved, and is non controversial. This is because shipping has been the goal of the entire effort. Crossing the finish line, while it has intangible emotional and definite financial rewards, is no surprise when you’ve observed every single painful step toward it.
The only reason you’ve been able to make these micro-observations is because you got to a known state and stayed there, and...