Babylon 5 is a story about two differing philosophies. The Vorlons promote a life of order, stability, and peace. The Shadows promote a life of chaos, destabilization, and conflict. There is a similar philosophical difference in software development.

Hubris of Prescience

Most commercial software projects lean toward a philosophy of order, stability, and peace. Optimism leads to anticipating stable requirements, which would allow for a stable design. This outlook influences management and developers to behave in a particular way. We gain an expectation for requirements and design to be orderly, stable, and for a peaceful progression of events to ensue. Successful methods and techniques are expected to continue to be viable. The products of past investments into research are expected to retain their value with the passage of time. Knowledge of the present incubates confidence in being able to anticipate future needs. This confidence is reinforced by the belief that momentum has longevity. This belief is correct, but not in the way that we would hope for a healthy technology business.

The technology market relies upon continuous innovation. Innovation is about disruptive change. A strategy based on incremental improvement bets on a steady pace of change, where one’s own product is the market leader. Trailing competitors are constantly seeking to impose revolutionary change upon the market to overtake the market leader. If one is not in the lead, then it makes sense to disrupt the market to put oneself in an advantageous position. New markets are created, where old ones are destroyed. Competitive innovation radically alters requirements, thereby invalidating entrenched designs. Disruptive change accelerates demand for technology through obsolescence.

The lure for the market to adopt innovative products is efficiency gain. Gains in efficiency increase productivity or reduce costs – or both. A methodology promoting the entrenchment of a status quo is unable to adapt to an environment of unrelenting disruptive change. In technology, the status quo is precisely what must be destroyed in order to sustain a healthy market. A strategy of maintaining an entrenched design is a strategy of certain failure in the technology market.

Creativity and Renewal

While a life of order, stability, and peace breeds comfort, it also leads to stagnation and complacency. Creative individuals will recognize where the status quo is not good enough. A culture that institutionalizes the status quo cripples creativity, ensuring a disadvantage in relation to the competition, who seeks disruptive change.

Innovation is nurtured by an entrepreneurial spirit. There are several factors that are required to facilitate creative thinking: freedom, motivation, inspiration, and courage. Creativity needs a culture that promotes creative ideas by nurturing independent thinking, not obedience to instructions delivered by management or designated “thought leaders”; individuals will be willing to think if they are entrusted to do so. Motivation comes from achievable goals, incentives, and the rewards of a job well done. Inspiration comes from the growth and enjoyment of working with peers, who demonstrate competencies, which become a source of knowledge. Finally, courage is provided by the willingness to incur risk to achieve the rewards that come from unconventional thought; people who are confident enough in their ability to attempt great things should be encouraged to do so, because overcoming technical problems is daunting enough without the burden of an unsupportive culture.

The key characteristic of a technology business that is prepared for innovation is agility. It must be adaptable quickly to change. It must embrace disruptive change, and use change to its advantage, rather than being resistant or vulnerable to it. This includes a high degree of tolerance for risk, because change is inherently risky, and the more disruptive the greater the risk (and potentially the reward). Innovation opens opportunities, but a business must be able to pounce on an opportunity to benefit.

Until Moore’s Law no longer holds, we can expect innovative growth to continue. Technology innovation and obsolescence is the dominant trend. A technology business that does not institutionalize a culture that embraces disruptive change will not be a business for long.

In my previous article, maturity as the enemy of innovation, I identified the destructive forces of organizational maturity. As an engineer, I cannot allow a problem to go unsolved.

To stem the tide of chronic risk aversion, we must imprint the entrepreneurial spirit into the culture as a core value. The courage to initiate calculated risk-taking needs to be admired and rewarded. The stigma associated with failure must be removed by appreciating the knowledge gained through lessons learned.

The cost of research and experimentation must be reduced. The pace of development must be rapid. These are achieved by keeping the team size small. The most risky and unproven ideas should be attacked by an individual, not a team. Functional teams need alignment on direction and a degree of agreement. Revolutionary advancement is frequently the result of radical thinking. New directions, different techniques, and breaking well-established rules are unpopular, especially to those with emotional investments in past innovations. There are fewer disagreements in a small team, and none at all in a team of one.

Uniformity of thinking leads to stagnation. Diversity must be encouraged, and this is promoted through a free market for ideas. Organizations that rely on a command-and-control style of management to set direction eliminate the competition that nurtures a diversity of ideas. Management should empower technical decision-making to be done bottom-up rather than top-down.

Once new ideas have been adequately proven, there must be ways of teaching them to others and incorporating them into product. Product development is often done sequentially, one release at a time. The immediate release focuses on short term commitments, and the delivery is usually constrained by schedules and costs that can ill afford risk. Riskier development must be allowed to proceed concurrently on longer-term schedules, without overly constraining the process. Developments from the unstable branch should be merged into the main product release, as they become ready. This provides an environment to accommodate both risky development and risk-averse development.

The above techniques can be effective in remedying the organizational impediments to innovation. However, there are also commercial impediments that must be overcome. That will be the topic of my next article.

As a software development organization matures, its culture institutionalizes practices that promote quality. Maturity is for quality. The most obvious measures of quality are in terms of defects. The quest for lower defect counts is a noble one.

At the same time, complexity grows as the weight of larger feature sets and lofty requirements are incorporated into the software. With increasing complexity comes a larger development team. A larger team means more division of labor, higher cost of management overhead, and more careful planning to be able to utilize those resources. Division of labor requires the delegation of distinct responsibilities to specialized roles. Decision-making becomes more dispersed and distributed, and a decision will have wider impacts on team members, so good communication becomes a critical success factor.

Unfortunately, decision-making, communication, and the distribution of responsibility are never perfect. The more complex the software, the larger the team, the more distributed the responsibilities, the more specialized the roles, the higher the cost of development. This is not a scalable organizational model. Once a software organization has reached this stage of maturity, it is doomed by inefficiency. Creative individuals are no longer empowered to quickly realize their ideas. Two key requirements to motivate and nurture a creative mind are independence and freedom. The degree to which these environmental factors are blunted is the degree to which innovation is impeded.

Because decision-making is distributed among many people, it becomes impossible for innovative ideas to be realized without winning consensus. Innovative ideas are unconventional ideas. A novel approach often needs to break well-established rules and go against practices that have worked in the past. Innovation is destructive to the status quo. It must be disruptive in order to rise and overtake older practices. Innovation is the product of experimentation and risk-taking, usually resulting in failure and rework. Without an environment that encourages this, there will be no innovation.

The quest for quality through institutionalized practices and disciplined management are in many ways counter to the independence and freedom that motivate a creative mind. Careful project management and planning discourages experimentation with risky new ideas (technical, organizational, and commercial), where many unknowns make results difficult to predict. Risky ideas need experimentation so that many failed attempts can be discarded quickly, allowing successful ideas to be taken to production. Mature organizations respond to higher risk by applying stronger management practices for mitigation, thereby increasing the cost and slowing the pace of failure towards success. In fact, once management smells failure, they immediately work to eliminate it, thereby destroying its very value as a vehicle to learn what will be needed to succeed. This is how many mature organizations have killed off the entrepreneurial spirit. This is the reason why most innovative ideas come from small groups of individuals working in a garage or a small start-up company.

We spend an extraordinary amount of time planning our development, because it is so costly to get any amount of code written. Developers are asked to give estimates. They demand to know what is in scope down to the individual operation. It’s crazy how much design work and detail needs to be thought through before reaching that point. Then, they estimate maybe 10-20hr of work per method. Even a tiny piece of functionality results in estimates in several person-weeks of effort. This is how software professionals get their jobs done.

Where have all the hackers gone?

I came up with a cool idea on the weekend. I decided to code it sunday. I spent about four hours in total coding the entire thing, analyzing and designing, as I went. It turned to be over 2000 lines, which I proceeded to unit test. I put in another three hours tonight debugging a rather obscure problem (actually wasting 2.5 hours chasing a non-existent bug due to my own stupidity), which I discovered in my sleep the other night.

I simply cannot understand why experienced software professionals cannot hack out 3000 lines of unit tested code on a good day, and average 1000 lines of unit tested code per working day, with low bug counts.

I’m almost glad to see that many of North America’s grunt coding jobs are being outsourced to India. The cost of our software professionals in combination with their low productivity and high maintenance attitude is unbearable.

Software development methodologies such as the Unified Process are intended to institutionalize a quality process.

Often, the manner in which a quality process is implemented will focus on quality of manufacturing, in order to achieve predictable schedules and outcomes. In the name of predictability, rigorous up front planning attempts to predetermine tasks, resources, and schedules to estimate costs and deliverables. Putting constraints on the size and shape too early will necessarily require gross assumptions about the requirements and design. In so doing, we have traded off quality of innovation to achieve quality of manufacture. We are able to build it within budget and on time, but what we are capable of building is not innovative.

When faced with designing objects, many developers immediately try to identify the abstractions. They have a preconception that the world must be organized as a hierarchy of abstractions. They quickly run into situations that don’t fit nicely into their hierarchy. They struggle to force-fit things into this model. After a while, they ask for help.

The world is not a tree. There may be forests. But generally the world is what it is. Do not force things to be a part of a tree, when that is not what they are. That should be obvious enough. It is always the most obvious things that are difficult to realize, when one is blinded by misconceptions.

Step 1. Identify the concrete types. Start from the objects that will actually exist, not from higher level abstractions. The concretes have definite characteristics that can be analyzed. These characteristics are where the abstractions will be found later through refactoring (unit economy). Concretes are characterized by their behavior. A concrete has roles and responsibilities relative to other objects with which it collaborates. It may be necessary to decompose a concrete into smaller parts that take on those distinct roles and responsibilities (separation of concerns) more clearly.

Step 2. Refactor the characteristics into higher level abstractions. Identify characteristics and behaviors that are common across concretes. Often behaviors can be seen as actions performed on the concretes (rather than actions performed by the concretes), and there is a distinct characteristic that each action depends on. I frequently call such a characteristic a capability, and the action is known as a generic algorithm. As this refactoring proceeds, the generic algorithms and the capabilities are identified as higher level abstractions shared or applied across concretes.

Step 3. Refactor the algorithms and capabilities. As the generic algorithms are implemented against the capabilities of the concretes, the methods will often benefit from factoring out commonality (duplicate code). Parts of the algorithm may benefit from being specialized through pluggable policies. These motivations identify additional abstractions at finer granularities. The finer grained parts of algorithms will likely act upon finer grained capabilities on the concretes. Broader generalizations and narrower specializations appear in the model as a consequence of this iterative approach due to refactoring to reduce complexity (the complexity is refactored to become encapsulated within objects, which are more manageable than messy algorithms).

The resulting model is forests of trees, along with lions and tigers and bears, as well as all the other concretes that exist in the world. Things as they really are. The way it ought to be.