If We Had Done The Right Thing To Begin With

Error-avoiding is overrated. Too often people want to wait surprisingly long periods of time before making a move, in fear that their move might be the wrong thing to do. The amount of fear and pre-thought we put into projects can be staggering.

I'm not here to say that design and architecture and platform design aren't important. Clearly there is value to having a workable plan and a goal in sight.  However, the idea that you must be right on the first day of development flies in the face of all our experience with application development. You only need to be "right enough" at first, and able to correct as time goes on.

We can become invested in concepts, ideas, development stacks, and architectures to the point that we forget that all up-front design decisions are just guesses. It's akin to a man walking up to the blackjack table with the intention to draw twice on the first hand and once on the second, even though those hands have not been dealt. The problem is that many smart developers will stick to the plan even if it fails to make development fluid and predictable, but if the gambler draws an 18 he wil decide not to draw twice after all. Do we realize that design is a bet? Do we continue to evaluate it, or do we take it as law on the day it is handed down from The Architect?

There are a small number of problems with being "right to begin with":

1. You'd have to know what "the right thing" is. A lot of systems have emergent designs that surprise their developers. Larry Wall is famous for saying that he had no idea Perl would look like it does today. An application may be written well in many ways, how can you know the One Right way in advance of actually building it? 
2. You'd have to know that "the right thing" is right. In a system with many choices, any number of right-seeming ideas may be wrong. The iPhone showed us that a radical design may be more right and more influential than many conventional ideas of what is right. Countless other unnamed products have shown us the reverse. Being convinced of the rightness of their conventional design, one large mobile phone company ended up missing out on the most lucrative phone design of our lifetimes.
3. "The right thing" would have to already exist. It might be that the innovation your product needs will be invented/released/discovered six months into your product development effort. A Lean Startup approach involves constant "persevere or pivot" decisions, which can be applied to architecture as well as feature set.
4. The cost of discovering "the right thing" up-front needs to be less than the cost of discovering it through experimentation and development. If you took three months to design a system, and you could have discovered the same solution by building three three-weeks prototypes, you were not being responsible but wasteful. Always remember that design is a gamble. 

The alternative is to learn and adjust as you go. It's no surprise that this is how software projects have succeeded (when they've succeeded) over the years.

From Agile Otter Blog

Architectural decisions are hard to make once-for-all in a system where functionality and platform and development practices change fluidly. A good choice of language, platform, and early features will give us a good early start, but these decisions need to change (with requisite changes in code) if they no longer serve the needs of the business, which includes the need for fluid delivery of functionality to customers.

Maybe finding the right thing is a combination of up-front thinking and ongoing discovery; maybe it always has been.