Be extra cautious of early decisions in your development cycle

I do not see how can anyone disagree with The McDonald Theory which states that initiating a process is more important than finding the ultimate solution at once.

In deed this is how science and technology are progressing and naturally the same principle applies to any human activity which can tolerate a trial and error sequence of experiments. This theory is especially truth software development which is still in its infancy having a lot of room for further evolution and standardization.

Trivial Initial Decisions Can Eventually Become Serious Limitations

Experience teaches us that early decisions taken under the assumption that it will be easy to change in later stages as our project will be maturing usually stay with it for the rest of its life span.

Any developer has stories to say about a quick and dirty class he wrote under the pressure to present a case study, that despite his intention to replace it with something more strategic during the later stages of his development, it quickly became such a vital point of the platform so the cost of re factoring it is so large so he is preferring to just accept it as it is an leave with it even if it hurts the elegance and functionality of his solution.

Having several of this type of early code components that cannot be eliminated are most of the times the reason why eventually a platform is reaching the end of its lifespan and a rewrite is required.

The adaptability of a system dictates its success

As a system matures and extends its significance as a component of the whole ecosystem, it needs to satisfy additional requirements that most of them were not part of the original specification.

The ability of the system to serve such a need, is the challenge that will prove it successful and well designed. At this point it becomes obvious how important early decisions are becoming and how easily a seemingly nave design concept that became impossible to replace can gradually covert a system to obsolete.

The two extremes

In real world these directions can range between the two extremes of cowboy coding to literate programming.

The former referring to the heroic programmer who shooting from his belt, does not hesitate to hack around crafting his solution on the go, starting coding with little to no planning, while the latter is a term coined by Don Knuth as a method requiring a complete description of a program in a hard copy form (like a notebook) before a single line of code is written!

None of these styles should become a religious belief restricting the flexibility of the developer to select what he thinks is the best approach for the specific problem. Nothing can substitute the judgment call of the developer who needs to have to necessary blend of experience, talent and knowledge to successfully select the optimal approach based in the nature of the system he is trying to develop.

The design iterations

Designing a software system starts from a domain challenge which describes the problem to be solved.

The developer does not need to be an expert on the domain but he needs to be able to estimate the required depth of its understanding.

He should be capable to switch from a telescopic to a microscopic view while collecting requirements and more than this help his business experts to understand better what exactly they are doing and what they need.

Once the developer thinks he has reached a sufficient level of domain logic the next step should be to process all the available data and concepts expressing a possible solution which always must be accompanied by a list of the unknowns.

This process should be repeated until both the quality of the solution is acceptable and the unknowns are minimal and their possible source defined. Understanding the unknowns is extremely critical for the success of an implementation and most of the times this step is completely ignored.

Note that we should try to maximize the quality of the application, minimize the unknowns and minimize the estimated cost of its development.

It Drills down to Talent and Experience

Based in his experience, the developer will categorize the problem as either a standard or substandard one. This means that if he has gone through something similar before his task is simplified something that is is not true if he is facing a completely new problem than whatever he has resolved in the past.

At this point, I think that it is obvious that arriving to the optimal decisions relies more to the experience and talent of the developer and it is less of an engineering task that can be answered scientifically.