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.
"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.
"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.
"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
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.
"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.
"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
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.
"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.
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 firstname.lastname@example.org.