Law # 1 and Law #2

In my 30 years in this industry I have practiced, preached, or bemoaned every software development process from Waterfall to Extreme Programming. And I am still constantly learning in my consulting and training engagements. But in these years everything I have learned affirms these fundamental truths about software process:

1. Process is not skill – a quote from Jim Highsmith.
2. People succeed or fail, not processes.

Let me briefly explain. “Process is not skill” is a statement that no matter how perfect your process, it is always the envelope within which the business work is done by people. And the process is useless if the people doing the work do not have skill, insight and intuition bred from experience. Processes do not succeed or fail, the people do. A defective process can lead people to failure. A supportive process can guide people to success. But both of these scenarios can easily be transformed to the opposite result through the actions of the people acting within that process.

My experience led me to two “laws” that I follow on every project.

Law #1: Your first attempt is wrong.

This means your first use case is wrong in some way. Your first class diagram is wrong. Your first project plan, marketing plan, and your first code is wrong. In other words, you can’t make it perfect up-front. And whatever you are producing, your first result, version, or deliverable will be incomplete, incorrect, or defective in some way.

This should be a very liberating idea for the retentive among us, and there are many of those among us. When I share this idea with students or project groups, half the team squirm with discomfort. These are the ones who have the psychological bent, inclination, or motivation – actually, need – to “get it right up-front”.

But they never do “get it right up-front”. On casual questioning even these closet perfectionists admit they have never attained their ideal of producing the perfect requirements specification, or use case, or functional specification. But still they hold fast to the idea that they could, and will do so, eventually. This is a myth that seems impervious to empirical fact.

And many otherwise rational people buy into this myth by defining development process that they are certain will define away mistakes and rework, and all will be well, efficient and profitable. But these processes are also subject to Law #1, which itself stems from the reality of imperfection and uncertainty. Imperfection cannot generate perfection, no matter how hard one tries. The best novel writers – Hemingway, Proust, Faulkner – understood Law #1 and never wrote just one draft. They re-wrote and re-wrote until they knew the work had become “good enough”.

James Dickey, one of our significant 20^th century American poets (he also wrote the novel that the movie Deliverance was based on), was asked once, “Mr. Dickey, how do you know when a poem is finished?”  Dickey didn’t even hesitate, and in his rich Georgia drawl he replied, “Well, actually I don’t. I just decide to abandon it.” This is honest brilliance that applies equally to software development as to writing poetry.

So, what is the result of our recognition that we cannot get it right up-front? That’s simple, and it is Law #2.

Law #2: Your next attempt is less wrong.

If your first use case, or spec, or class definition is wrong, then you iterate, and correct it. But your second attempt is still wrong in some way, just less wrong than the first attempt. And then you re-do and re-do until you decide to stop – or abandon it - when it is “good enough”. That is, when the document, artifact or code is good enough that it will let you move to the next step in your process.

This is the key criterion: is the content, accuracy, precision, and quality of what you are producing sufficient to let you move to the next step in the process, to make progress?

I believe it was General and U.S. President Dwight D. Eisenhower who said, “The value is in the planning, not the plan.”  In other words, expect to miss something, focus on the doing and be flexible. Then you will be prepared to react correctly when the omission or error becomes visible.

Law #3

What is this? Did I not start by saying there were only two laws?

Yes, I did, and I am not contradicting myself. I have added this to emphasize: there is no Law #3. You never “get it right”. There is no achievement of perfection. You can only get it “good enough”, so you can abandon it, move on, and perhaps come back again to revisit it with yet more changes to make it even more "good enough".  And how you define “good enough” will differ among companies, processes and projects. Another liberating idea is that you only have to define “good enough” for your context.

I encourage you to consider inviting Law #1 and Law #2 into your project.  They are very empowering concepts. Your project will never be perfect, but you will achieve “good enough” more quickly than you thought possible.