On the trail of Creationism, evolutionism and intelligent design, I wanted to introduce the notion of software DNA, which can be used to measure the quality of a project. There are several somewhat expected conclusions in the following posting but it is interesting to see Mother Nature at work in what is otherwise an aseptic activity.
We can all accept the notion of a "DNA" signature for a product, a sophisticated mesh of everyone's contributions to the final outcome. The interesting part of the analogy starts from how these contributions are distributed over time. Product development is a somewhat pipelined series of activities, with each stage requiring the intense participation from different sets of people. As the assembly moves on the pipeline belt, those sets of people donate their "DNA" to what is going to be the final product, compressing several generations of evolution in a matter of a few months.
In biology, a diverse pool of genes is a crucial factor for a successful species. The diverse DNA combination increases the odds that one will survive the harshness of the environment, while nature callously weeds out the less adaptable variants. Back to the software analogy, that diversity is equally important, originated from contributions from people from different backgrounds, with different expertise and perspectives on how the product should be shaped. Before I continue, think of it the next time you feel your participation is too small to make a difference.
From a customer perspective, that evolutionary diversity is beneficial as it results in better products. Even the powerful "species" coming out of the Microsoft pipeline can have their survival threatened by random mutations on foxes, owls, and penguins.
Although companies will try to influence the environment to improve the odds toward their offspring, environmental control is become increasingly difficult with long-tail markets emerging everyday. When environmental control becomes difficult to manage, the only hope for a company is to revert back to its own resources, carve the best product out of its gene pool and hope that the environment will be kind to it.
I already explored the importance of diversity in the early paragraphs; now let's take a look at mutations. Skunkworks, research, and an emboldened community of innovators are a fantastic start because they represent the random mutations in the gene pool. Some mutations are more beneficial than others and the environment can be harsh with seemingly superior species (can you say Betamax?)
But there is one gene we want to preserve in large and healthy doses in the final species: the customer genes. They are (or should be) injected on the first cells of a product and preserved in the final species at all costs. Skipping the business modeling phase for a project is an almost fatal handicap to any species. The lack of those genes makes the species unattractive and as soon as the parents exhaust their capacity to incubate it, it becomes extinct.
The lack of formal requirement analysis will also push those genes through the cracks in the pipeline. Here is a less obvious point. The new software is already in contact with the environment while it is being created. Once the customer genes are injected into the initial species, they are visible in the pipeline and some may be unpleasant to the DNA contributors. Without proper enforcement, an ill-controlled environment may become hostile to certain desired characteristics.
I do not see bodily rejections of the customer DNA in the software creation process as a sign of corruption or shortsightedness, but rather as a natural occurrence. While we do want the final product to preserve the customer genes, we need to acknowledge that they make the creation process harder. Without good safeguards for those genes, they become easy prey to a mismatched set of localized liabilities and greater goals.
As examples, even with the foreseeable disastrous results, assuming what a customer wants instead of actually asking the customer takes much less time and effort. In a large organization with experienced architects, those kinds of assumptions tend to fall on the creationist side of my previous posting titled "Creationism, evolutionism and intelligent design". If you ever take time to read, you will agree that software creationism is extremely hard to pull off.
Conversely, assuming that certain conditions will not be present during real deployment can save development time by avoiding more costly test injection techniques. The rugged reality of customer environments can be an exacting master to people making those kinds of assumptions. And if it was hard to debug it in the lab, try and imagine debugging it in the wild.
In the end, one can try to rely on common sense and good will, but nature is a mighty adversary. Creation of software is still an engineering practice, even when seen through biological lenses.
Know thy wall, mind your trenches. geekish alert. A few years back, a colleague introduced the notion of DevOps to an internal large au...
I watched with interest this TED presentation by Dan Ariely, titled " What makes us feel good about our work " and immediately not...
I have been meaning to document a bit more my experience as former Bluemix SRE and Operations Engineering Lead during 2014 and 2015, which ...