Dr. Carlo Pescio
17 Aphorisms of Software Development

Extended from an article published in IEEE Computer, August 1997.


Software development involves peoples with different skill, attitude, background, and education. Communication between persons with a so different mind-set is not easy, and lack of effective communication can hinder the development process more than any technological issue. An old-time strategy to foster new ideas is the use of metaphors or aphorisms: short, concise saying that are readily understood and accepted, because they build on the duality of the human mind: they carry non-verbal information in the form of analogies, inside an easy-to-grasp verbal message. Here I present some of the aphorisms that I've successfully used over the years as part of my consulting activity, to communicate with peoples from different countries and with varied culture, or simply to exit with elegance and eloquence from a "stalemate" situation; for each one, a few words of comment are given to consolidate the concepts. Some of them may please you, some may disappoint you - pick the ones you like, but think more about what makes you nervous: sometimes, disappointment is the first step toward a new perspective.


On patches
"A pain drives out another, but still you have a pain"
The result of quick programming and early errors is often a sequence of patches - especially when the manager or the developers are not willing to accept the cost of a new, complete, properly designed solution. Patching is just another kind of quick programming: a quick, local fix to a broken system, instead of a complete reengineering of the defective part. The patching-game rarely gives a safe, stable, correct product: it is more likely to expose deeper and deeper shortcomings of the former quick solution, as if you were peeling an onion - that's well known to make you cry.

On featurism
"A good architect does not yield to temptation: he resists to it"
A typical problem of today's programs is featurism: programs are bigger and bigger, and they continue to grow. If your competitor's program sports a new feature, yours must have it too; well, perhaps something more powerful and with more bells and whistles. But featurism does not come just from market competition: it is also the result of the lack of a clear vision for the project, an incomplete understanding of the customer's needs (analysis? we use rapid prototyping!), or today-oriented management. Featurism is the root of many evils, like short development schedules and hack-o-rama development.

On post-mortem reports
"If you stay in the dark for a while, you see everything very clearly"
A successful project is a source of pride and money; an unsuccessful project may be a source of knowledge. After the completion of a project, or after a significant milestone has been reached, you have a very clear vision of what did worked and what did not: that's why sometimes you'd like to restart the project with the new knowledge you gathered on the process. One of the best ways to avoid future mistakes and establish a best-of-practice record is to write down a post-mortem report, and act on your findings.

On quick programming
"The perfection of a clock is not in the speed of the movement, but in its correctness"
The "quick programmer" is not uncommon in software teams: you can spot him because he's spending most of his time fixing his own bugs. Actually, sometimes "fixing bugs" just means develop new code, because the old one was underengineered to the point it can't be enhanced without major rewriting. Quick programming is sometimes the result of management pressure on developers: in that case, the spontaneous quick programmers are often the only happy guys in a mumbling team. Quick programmers may be great in the development of throw-away prototypes - if the project manager does not try to recycle the prototype as a product.

On artist programmers
"Artists are never wrong - only unappreciated"
Software development is frequently perceived as an art - sometimes, as a black art. Most of the best programmers have a past of wizards, whose only will was to coerce a computer to do something it was not supposed to do. But the very best programmers have been enlightened by a formal education and real-world experience in big projects. The artist programmer is often great in the development of small gems of assembly programming, where an intimate knowledge of the of the graphic-card-last-bit may be useful; that does not mean he can design a complex software system. Even worse, artists are very difficult to deal with: they are never wrong, you are simply not smart enough to understand their art.

On the "we'll fix it later" attitude
"Wounds heal, but the cicatrix grows with us"
Everybody knows that the cost of a bug increases if you fix it later, and that errors in the early phases (e.g. specification) cost more than errors occurring in the latter phases of development. Still, when faced with an almost-working solution, too many programmers and managers are tempted to "keep it until next major release", or "keep it until we find a better solution". Too often, a better solution is never sought: new problems, new challenges, new ideas lead to accept the far-from-perfect solution as an unavoidable legacy. Even more often, the shortcomings of the first solution act as limiting factors in the development of the whole project, as a cicatrix that grows and remains even when the tissue is finally healthy.

On guts
"Some things are not dared because impossible, some things are impossible because not dared"
Management always tries to minimize risks in the production process; that includes software development, when it is considered a production process and not a Research&Development activity. It is then natural to avoid complex solutions, in favour of sub-optimal, easy, risk-free paths. If you look at the flat market of horizontal applications, in terms of features and interaction, and if you consider how unhappy are the users of most systems, you have a very clear picture of how little is dared in software development nowadays. You never get innovation without risk.

On pilot projects
"It's easier to start a new company than to become the president of a blue-chip one"
The typical human reaction to innovation is resistance, fear, discomfort: after years of tried-and-true practice, here comes something new come to break habits, force to learn new concepts and to abandon the safe feelings of experience. That's why is dangerous to introduce new technology into an old project, unless the team is strongly committed and motivated; often is better to gather the peoples who are interested, and try out the new ideas on a pilot project. Never underestimate human resistance and the persistence of old habits: one can really program in Fortran in any language.

On global vision
"The player's attention is on the instrument, a composer thinks to the whole opera"
Designers and programmers have a different role, different mind-set and often different education and experience. It is common to see programmers that provide quick, largely underengineered solutions: their focus was on the satisfaction of the immediate, local needs, without concerns on the big picture. When a single programmer can maintain the conceptual integrity of a project, there might be no need for an experienced designer - but in most real-world projects, you definitely need one.

On lack of investigation
"The scorching and the cold glass are indistinguishable at a first look"
When you look at the time schedules for most project, it is not a surprise that programmers and managers have a tendency to jump on the first solution that seems to fit the problem. It is rare to have enough time to investigate the pros and cons of different solutions, and then select the most appropriate according to present and future requirements. Still, software development is largely a Research&Development activity, more than a mainstream production job; without investigation, failure is on the track for any complex software project.

On too small steps
"You cannot pay for death by sleep instalments"
Under the battle cry of "incremental development" we can see the evil of underengineered solutions, hiding itself between one cycle and the other. While the incremental approach is often good, we should not pretend to split any and each activity into atomic steps: new algorithms are not devised incrementally, architecture is hardly definable using a small subset of domain analysis, hardware/software codesign often needs extensive thinking, and so on. Some activities take time, and artificial partitions only prevents the optimal solution to be found; in Wlad Turski's words "to every complex problem there is a simple solution... and it is wrong".

On How and When
"You cannot look in the Bible for the address of a good restaurant in Palestine"
Peoples like certainty - so when something works well, or when they are good at doing something, they have a tendency to use the same technique in every conceivable situation. For any given task, factors like scale, access patterns, time constraints, reliability, maintainability (to name a few) make some techniques more suitable than others. An expert developer knows how and when a technique or tool must be used, and can balance the qualities of different approaches; conversely, bigotry is most often the label of inexperienced newcomers, breed in the cotton wool of toy projects. Experience, flexibility, knowledge and education walks together to shape the best software developers.

On total quality
"A disaster is often a sequence of apparently harmless, little mistakes"
A recipe for failure in software projects is to ignore the drift from established targets. In the beginning, small errors take us far from the ideal road, but not that much; then, the more you go ahead on the path, the bigger the distance from your goal. Confusing activity with progress is always an hidden risk, unless you monitor the adherence of the products to the specification; because you do have a specification, don't you.

On "persuasion"
"Stakes never shed light into the darkness"
Sometimes a goal is so important, and the management so committed to reach it, that it's easy to slip into the "lean and mean" attitude. That often means threatening programmers to work harder: useful techniques as peer-reviews are then abused to move programmers into an uncomfortable position, metrics are blindly used to award the one who writes more lines, and penalize the one that tries to reuse existing code. On the long term, it never pays off: a pleasant working environment is one of the distinguishing traits of the successful companies. Check the turnover of your staff to see how good is yours.

On conservatism
"Some aborigines are used to eat their own parasites; if you ask them why, they say: 'we always did that'"
Strategies aren't necessarily portable from an environment to another, from a language to another, from a problem to another. You must always maintain an open mind and be able to analyse your bag of tricks at the light of evolution. Should you use unreadable naming conventions, devised for languages without type checking, together with a state-of-the-art, statically typed language? Should you use functional decomposition when you program in C++? Maybe not - unless you like fleas.

On bloated teams
"Lot of soldiers don't a good general make"
Effective teams are small: that helps to maintain conceptual integrity, avoids genetic drift, and facilitates communication. Still, lack of timeliness, planning and risk management, the inability to defend schedules, and shortage of vision often result in more and more peoples added to a project, in a hopeless tentative to compensate management failure with manpower. In Brooks's words, man-months are - indeed - a myth.

On cannot-estimate
"Before I step into a puddle, I'd like to know how deep it is"
Beware of the developer who can't give you a decent estimation of the time necessary to accomplish a task; he is at best inexperienced, at worst an indisciplined hacker. In the first case, a good mentor can help him to exploit his full potential; in the latter, ask yourself if you really don't have any better choice: peoples are a critical factor in software development, and there is little excuse on betting your success on the wrong ones.

Reader's Map
Several visitors who have read
this article have also read:

Biography
Carlo Pescio holds a doctoral degree in Computer Science and is a consultant and mentor for various European companies and corporations, including the Directorate of the European Commission. He specializes in object oriented technologies and is a member of IEEE Computer Society, the ACM, and the New York Academy of Sciences. He lives in Savona, Italy and can be contacted at pescio@eptacom.net.