Tag: Descartes

Why do software projects fail? is not a philosophical question in Descartes’ sense, that is one that can be decomposed in order to arrive at a practical solution.  Rather, it is a contemplative problem in Aristotle’s sense: one that can be looked at in many ways in order to reveal something about ourselves.

 

Software projects fail because we are weak.  We can make software projects better not by becoming stronger, but by minding our own weaknesses.  The truth is that software programming has made a lot of progress over the past twenty years.  It has not made it along the via positiva, however, through solutions such as OO, or Design Patterns, or Agile, or SOA, or a host of other white knight solutions that over time have turned out mostly to be hype.

 

Rather it has progressed through the via negativa, or by learning what not to do.  The via negativa was originally a mode of theological discourse, mystical in essence, which strived to understand God not in terms of what He is, but in terms of what He is not.  This mystical path serves well in pragmatic matters, also, and below I will outline some principles of the via negativa as applied to software development. 

 

I should include the caveat that I am not sure these principles have ever worked well for me, and that I continue to underestimate the scope of a task and the amount of time it will take to finish it.  On the positive side, I believe it all could have all been worse.

 

The Via Negativa of Software Development

 

1. Programming is neither an Art nor a Science

The thing I like best about Hunt and Thomas’s book The Pragmatic Programmer is their attempt in the first chapter to analogize the act of programming to the Medieval journeyman tradition and the concept of craft.  I liked it so much, in fact, that I never bothered to read the rest of their book.  The point of thinking of programming as a craft is that we escape the trap of thinking of it in other ways.

 

Many programmers think of coding as an art, in the romantic sense.  Every project is new and requires a new solutions.  The solutions a programmer applies constitute a set of conceits that express the programmer’s own uniqueness.  Rather than applying mundane and known solutions to a set of programming problems, the artist coder prefers to come up with solutions that will express his originality.

 

On the other side, some programmers think of coding as a science.  There is a set of best ways to accomplish any given task and their role is to apply that perfect solution.

 

Between these two is the notion of programming as craft.  There are a set of ways of doing things, such as retrieving data from a database or displaying them for data entry.  The craftsman’s goal is to accomplish his tasks in the ways he knows how to do it, whether they are the best or not, with as little waste as possible.  The craftsman’s motto is also Voltaire’s: Le mieux est l’ennemi du bien.

 

2. Don’t Invent when you can Steal

A corollary to the craftsman’s motto is not to invent what you can steal.  One of the biggest mistakes that developers make is to assume that their problems are unique to them.  In fact, most problems in programming have been faced before, and developers are unusually generous about publishing their solutions on the Internet for others to use.  Good design should always involve, early in the process, using Google to find how others have solved your problems.  This is somewhat different from the Patterns frame-of-mind which assumes that there are common theoretical solutions to recurring problems.  What you really want to find are common implementations, specific to the language and platform you are using, to your programming needs.

 

This was a well-known and commonly applied rule in the early days of radio.  Comics would freely steal jokes from one another without attribution, and occasionally would complain about how many of their jokes were being used on other stations.  What the radio comics knew, and we need to relearn, is that the success of the punchline depends not on the setup, but on the delivery.

 

3. Smells are More Important than Patterns

Software changes too quickly for patterns to be useful.  By the time patterns are codified, they are already obsolete.  With experience, however, also comes a knowledge of what doesn’t work, and it is rarely the case that something that hasn’t worked in the past will somehow magically start working in the present.

 

A smell is a short-hand term for things you know will not work.  While Richard Feynman was known as a gifted physicist at Los Alamos during the Manhattan Project, his peculiar talent was in intuiting what not to do.  He would go from project to project and, without knowing all the details, be able to tell those involved wether they were on the right path or the wrong path.  Eventually, his intuition about such matters became something other physicists respected and relied upon.

 

Feynman had a natural gift for sniffing out bad smells, which he couldn’t completely explain himself.  With experience, we all come to develop a good nose for smells, which manifest as a sense that something is wrong.  The greatest trick is to trust our respective noses and take smells into account, so that smells become identified as risks which deserve to be monitored.

 

Here are some common smells that emanate from doomed projects:

• Taking process shortcuts
• Too many meetings in which nothing is accomplished
• Custom Frameworks
• Hysterical laughter (oddly a common phenomenon when people start realizing there is something wrong with the project but are not willing to say so)
• Secrets between development roles
• No time to document
• No project plan
• No hard deadlines
• No criteria for the success of a project
• No time for testing
• Political fights between development roles (these are typically a symptom of a bad project, rather than a cause)
• Managers who say that everything is on track
• Managers who initially were setting themselves up to take all the credit are now positioning themselves to avoid all blame

 

4. Shame Drives Good Code

The most successful innovations in software development over the past twenty years have been shame based.  Pair-programming works because there is always a second set of eyes watching what we are doing.  It is difficult to take shortcuts or ignore standards when someone else is likely to call one on it almost immediately.

 

Code reviews are a more scattershot approach to the same problem.  Given that a code review can treat any piece of production code as a topic of analysis, it behooves the programmer to add comments, break up methods, and a host of other good coding practices in order to avoid having other developers point out obvious laziness. 

 

QA groups are the ultimate wielders of shame as a tool to drive good development practices.  QA brings obvious mistakes to light.  A developer who might try to slip in bad business logic without first verifying that it works, on the self-assurance that it should work, is less likely to so if he knows his private malfeasance might be brought to public light.  While QA is typically bad at catching problems with deep programming logic, they can instill a sense of shame in developers that will lead them to verify and thoroughly unit test their deep logic as they would test their shallow logic, knowing that others are watching. 

 

5. Manage Risk, Not Progress

All the points above are programmer-centric.  Manage risk, not progress is an essential rule for managers, project managers and business analyst.  Because programming tasks can be shifted around, it is common to put off difficult problems till the end, simply because one can.  This makes project plans, which measure all tasks with a common rule stick, notoriously bad at predicting the success level of a project at any given time.

 

Measuring risk is a better way to determine the success of a project.  To my thinking, identifying risk and determining whether risks have been overcome is the chief role of a good project manager.  If he spends the rest of his time surfing the Internet, I couldn’t care less.  Unfortunately, many project managers insist on reading self-help books about leadership and interpret their role to be one of offering inspiration to others.  They often view their roles in this way to such a degree that they tend to refrain from tracking risk, which is always a downer.  And the best way to avoid tracking risk is to never identify it in the first place.

 

6. The Code Must Flow

Code must be treated as disposable.  It must be treated as a commodity.  It is a common feature of coding to treat every piece of code as special.  On the other hand, we know that it isn’t true when we review our code months later.  What is truly gained in coding through a problem is not the physical code itself, but the knowledge of how to solve the problem. 

 

By constantly coding through every phase of a project, we gain knowledge of the problem domain.  By disposing of our code when we know it doesn’t work, and starting over, we learn not to make fetishes of our code.

 

The second worst programming practice is when a prototype is turned into a real application.  This is a problem for developers.  It seems like it will save time to simply build on the same code that we started prototyping with, despite the fact that it fails to implement good practices or commenting or any of the other things we have come to expect from good code.

 

The worst programming practice is when management asks how long it will take to release a prototype, and demands the code be sent out as is.  There is no answer to this worst of all programming practices, for while nothing can straighten out the crooked timber of humanity, poor management can always warp it further.

In the Theatetus, Plato writes that ‘philosophy begins in wonder’.  Here is Jowett’s translation of the passage:

Soc: …I believe that you follow me, Theaetetus; for I suspect that you have thought of these questions before now.

Theaet. Yes, Socrates, and I am amazed when I think of them; by the Gods I am! and I want to know what on earth they mean; and there are times when my head quite swims with the contemplation of them.

Soc. I see, my dear Theaetetus, that Theodorus had a true insight into your nature when he said that you were a philosopher, for wonder is the feeling of a philosopher, and philosophy begins in wonder. He was not a bad genealogist who said that Iris (the messenger of heaven) is the child of Thaumas (wonder).

In the Metaphysics, Aristotle continues the same theme (tr. W. D. Ross):

For it is owing to their wonder {ex archês men ta procheira tôn atopôn thaumasantes} that men both now begin and at first began to philosophize; they wondered originally at the obvious difficulties, then advanced little by little and stated difficulties about the greater matters, e.g. about the phenomena of the moon and those of the sun and of the stars, and about the genesis of the universe. And a man who is puzzled and wonders thinks himself ignorant (whence even the lover of myth is in a sense a lover of Wisdom, for the myth is composed of wonders); therefore since they philosophized in order to escape from ignorance, evidently they were pursuing science in order to know, and not for any utilitarian end.

This wonder tradition in philosophy has two principles. One is that wonder must lead to the articulation of questions, for without questions and dialectic, wonder never goes any further.  The second is that questioning must be non-utilitarian, and that its end must be contemplation, rather than the solution to a practical problem; in other words, questions must be open-ended in order to count as philosophical (i.e., pure scientific) problems.

Thus Aristotle continues, in Book II of the Metaphysics:

The investigation of the truth is in one way hard, in another easy. An indication of this is found in the fact that no one is able to attain the truth adequately, while, on the other hand, we do not collectively fail, but every one says something true about the nature of things, and while individually we contribute little or nothing to the truth, by the union of all a considerable amount is amassed. Therefore, since the truth seems to be like the proverbial door, which no one can fail to hit, in this respect it must be easy, but the fact that we can have a whole truth and not the particular part we aim at shows the difficulty of it.

Against this tradition, Descartes, an extremely practical man, argues in Articles 77 and 78 of Passions of the Soul (tr. Stephen H. Voss):

Furthermore, though it is only the dull and stupid who do not have any constitutional inclination toward Wonder {l’admiration}, this is not to say that those who have the most intelligence are always the most inclined to it.  For it is mainly those who, even though they have a good deal of common sense, still do not have a high opinion of their competence [who are most inclined toward wonder].

And though this passion seems to diminish with use, because the more one encounters rare things one wonders at, the more one routinely ceases wondering at them and comes to think that any that may be presented thereafter will be ordinary, nevertheless, when it is excessive and makes one fix one’s attention solely upon the first image of presented objects without acquiring any other knowledge of them, it leaves behind a habit which disposes the soul to dwell in the same way upon all other presented objects, provided they appear the least bit new to it.  This is what prolongs the sickness of the blindly curious — that is, those who investigate rarities only to wonder at them and not to understand them.  For they gradually become so given to wonder that things of no importance are no less capable of engaging them than those whose investigation is more useful.

Descartes found many ways to break with the Aristotelian tradition that had dominated Western thought for over a millennium, but none, I think, more profound than this dismissal of the wonder tradition.  In this brief passage, he places intelligence {l’esprit} above contemplation as the key trait of philosophizing.

A consequence of this is that the nature of philosophical questioning must also change.  In a Cartesian world, questions must have a practical goal.  Difficult problems can be broken down into their components, and if necessary those must be broken down into their components, until we arrive at a series of simple problems that can be solved easily.

Descartes’ position is only strengthened by what is often called the scandal of philosophy: why, given all this time, has philosophy failed to answer the questions it originally set for itself?

• Does God exist? 
• Is there life after death? 
• Do we possess free will?
• What is happiness, and is it attainable?
• What is Justice?
• What is Knowledge?
• What is Virtue?

Another way to look at the scandal, however, is not as a problem of lacking answers to these questions, but rather as a problem of having an overabundance of answers.  Philosophy, over the centuries, has answered the question of God’s existence with both a yes and a no.  There are five canonical proofs of God’s existence, as well as a multitude of critical analyses of each of these proofs.  We are told that Occam’s Razor, originally a tool of theological discourse, demands that we reject God’s existence.  At the same time, we are told that Occam’s Razor, the principle that simple answers are preferable to complex answers, itself depends on a rational universe for its justification; for the only thing that can guaranty that the universe is simple and comprehensible rather than Byzantine in its complexity, is God Himself.

The scandal of philosophy is itself based on a presupposition: that this overabundance of answers, and the lack of definitive answers, is contrary to the purpose of philosophical questioning.  Yet we know of other traditions in which the lack of answers is indeed a central goal of philosophical questioning.

Zen koans are riddles Zen masters give to their students to help them achieve enlightenment.  Students are expected to meditate on their koans for years, until the koan successfully works its effect on them, bringing them in an intuitive flash into the state of satori. 

• Does a dog have Buddha-nature?
• What is the sound of one hand clapping?
• What was your original face before you were born?
• If you meet the Buddha, kill him.

I dabble in the collecting of questions, and with regard to this habit, the observation Descartes makes above about the curious “who investigate rarities only to wonder at them and not to understand them” fits me well.  One of my favorite sets of questions comes from Robert Graves’s The White Goddess, a book which, starting from an analysis of The Romance of Teliesin that makes Frazer’s Golden Bough seem pedestrian by comparison, attempts to unravel the true purpose of poetry and, in the process, answers the following questions:

• Who cleft the Devil’s foot?
• What song did the Sirens sing?
• What name did Achilles use when he hid from the Achaeans in the women’s tent?
• When did the Fifty Danaids come with their sieves to Britain?
• What secret was woven into the Gordian Knot?
• Why did Jehovah create trees and grass before he created the Sun, Moon and stars?
• Where shall Wisdom be found?

Another set comes from Slavoj Zizek’s Enjoy Your Symptom!, in which Zizek elucidates certain gnomic pronouncements of Jacques Lacan through an analysis of mostly 50’s Hollywood movies:

• Why does a letter always arrive at its destination?
• Why is a woman a symptom of man?
• Why is every act a repetition?
• Why does the phallus appear?
• Why are there always two fathers?

Modern life provides its own imponderables:

• Paper or plastic?
• Hybrid or Civic?
• Diet or exercise?
• Should I invest in my 401K or pay down my college loans?
• Should I wait to get an HD TV?
• When shall I pull out of the stock market?

There are no definitive right or wrong answers to these questions.  Rather, how we approach these questions as well as how we respond to them contribute to shaping who we are.  In his short work, Existentialism and Human Emotions, Sartre tells an anecdote about a student who once asked him for advice.  The student wanted to leave home and join the French Resistance.  The reasons were clear to him. The Germans were illegitimate occupiers and it was the duty of every able-bodied Frenchman to fight against them.  At the same time, the student had a sickly mother who required his assistance, and leaving her would not only break her heart, but he might possibly never see her again.  To leave her would entail sacrificing his filial duties, while not to leave her would entail abandoning his moral duty.  To this student, caught in the grips of a mortal quandary,  Sartre offered the unexpected advice: choose!

…[I]n  creating the man that we want to be, there is not a single one of our acts which does not at the same time create an image of man as we think he ought to be.  To choose to be this or that is to affirm at the same time the value of what we choose, because we can never choose evil.  We always choose the good, and nothing can be good for us without being good for all.

But this isn’t the whole truth.  There are also choices we make that appear arbitrary at the time, committed without any thought of ‘man as he ought to be,’ but which turn out to have irreversible consequences upon who we become.  In the film The Goalie’s Anxiety at the Penalty Kick, Wim Wenders follows a goalie who is kicked off of his soccer team after failing to defend against a penalty kick that costs his team the game.  The goalie proceeds aimlessly through a series of pointless and reprehensible acts.  I once asked a soccer-playing friend if the circumstances of the penalty kick are as they were described in the movie, and he said yes.  Before the penalty kick, against a skilled opponent, the goalie has no idea which way the ball will go.  He stands in the middle between the two posts and must choose which in direction he will leap, without enough information to determine whether his choice is the right one or the wrong one.  The only thing he knows is that if he does not leap, he will be certain to fail.

All these theoretical questions, and the survey of the theory of questioning in general, are intended to provide the background necessary for answering the very practical question:  Why do software projects fail?

Fred Brooks’s succinct answer to this is: software projects fail because software projects are very hard to do.  In other words, we are asking the wrong question.  A better way to phrase the problem is “Why are we still surprised when software projects fail?”

This question might be extended to other fields of endeavor:

• Why are term papers turned in late?
• Why do we fail to pay our bills on time?
• Why do we lie when we are asked over the phone, “Were you sleeping?”

In the discipline of software development, it is often found as one item in a larger list of software koans:

• Why do software projects fail?
• Why does adding additional developers to a project slow the project down?
• Why does planning extra time to complete a task result in no additional work being done?
• Why do developers always underestimate?
• Why are expectations always too high?
• Why does no one ever read documentation?
• Why do we write documentation that no one ever reads?
• Why is the first release of any code full of bugs?

Here we have an overabundance of questions that can all be answered in the same way.  Kant phrased the answer in this way:

Out of the crooked timber of humanity, no straight thing was ever made.

Aristotle phrases it thus in Metaphysics II:

Perhaps, too, as difficulties are of two kinds, the cause of the present difficulty is not in the facts but in us.