Introduction

There is a notion that exists in the zeitgeist of software development that “moving fast and breaking stuff ” results in high development velocity and reduced time to market. In this vein it is not uncommon for startups to create sweatshop environments where people work late into the night or sleep under their desks in order to develop product faster. These approaches share the common view that the harder you work people the faster your product gets out the door. And it is common understanding that if you work in a startup you will be expected to work long hours for many days or weeks until your deliverables go out the door.

Perhaps these notions came about from the early days of the software industry and served a purpose at some time. But it is questionable whether business understood what engineers went through and what shortcuts they had to take in order to meet the irrational demands being placed upon them. For the most part business men simply do not know what has been delivered to them or if it will work at scale or  perform gracefully under pressure. So long as the product looks like it is working, then that is enough for them. This emphasis on speed and breakneck coding results in products with inherent shortcomings, defects and instabilities that appear only in production and create constant critical errors for engineering to fix.

Software products are behavioral. There is no correlation between the number of clicks on a keyboard and the velocity of product development. “Move fast and break things” by itself, does not result in higher quality product or increase the velocity of product development. This so called axiom has been born out of a fundamental misunderstanding of agile development. It is true that Agile embraces failure as a means to evolve designs addressing that failure. But without understanding the purpose of the Agile approach, moving fast and breaking things only results in malformed and buggy software products.

Common Language

Much of the dissonance that exists between business teams and software teams lies in the opaque atmosphere that surrounds software development. By nature software development has languages, processes and models that are unintelligible to business people. When engineers use their domain specific language in conversations with business, it is literally “geek speak”and does not translate into notions that business can understand or value. Similarly when business communicates with software, they use terms and language that are alien to software development. In this relationship there are usually one or two people from either side who become translators and diplomats so that business requirements can be translated into software initiatives and software needs can be translated into business concerns.

In each organization the relationships between business and software varies – in some cases – significantly. The result is each organization has highly variable cultures resulting in highly variable product quality and deliverable timeframes.

The result of the conflict arising from this “confusion of tongues” requires a common language that both sides can understand. And this common language arises from the common purpose that business and software teams share. In fact this common purpose is the reason for the existence of the organization in the first place. So what is this thing that is common to the entire organization? It is the product.

The product is common to all departments in an organization. It is the reason for the existence of the organization in the first place. All stakeholders have a common interest in the product:

• Marketing wants to develop the market for the product.
• Sales wants to sell the product.
• Development builds the product.
• Business wants to make money off the product.
• QA tests the product.
• Operations launches and maintains the product in production.

It is arguable that most organizations do not have a living view of the product as it is being developed. The software lives in developers machines, QA machines and in version control systems like git. Nightly builds run unit tests on the product. QA performs integration tests on the product. And developers build the product on their individual machines. For the most part the product is not visible or usable, as it is being developed, by the organization as a whole.

A closer examination of the product reveals its features, user stories and importantly, the domain entities that are inherent to the product. For example, a banking application has entities like checking account, savings account, credit card accounts, transactions etc.  A social media application has domain entities like users, posts, groups, comments, messages, follows, and likes.

It is by understanding the product, and its domain entities as well as how a user interacts with that product that a common language surrounding that product can be developed. This is what domain driven design calls a ubiquitous language. An in depth study of the ubiquitous language can be found by reading Eric Evans book Domain Driven Design.

A Product-Centric Approach

The entire subject of the ubiquitous language is broad and deep but the essential point is that by focusing on the product, business and development can come to a mutual understanding of what is being built and why. However, this alone does not boost productivity or reduce time to market. It is a starting point for the next step.

In order for business and development to come to a shared understanding, they need a shared experience of the product itself. And not just the product as a whole, but the product in every stage of its development – from the first user story to the final product ready for launch. And while few organizations appear to have this facility, approaching software development in this way changes the dynamic between the business and technical teams. The benefits of this approach are::

• The reduction of friction between the business and development teams.
• The stakeholders experience functionality of the product for themselves.
• Stakeholders become part of the product review.
• The shared experience promotes the ubiquitous language.
• The shared experience leads to the discovery of hidden features.
• In-flight corrections and enhancements can be made more easily.
• It focuses the organization on the product.
• It reduces reports and managerial overhead.

Like everything else in the Agile approach, the discovery and development of the product, its domain entities, its features, user stories and ubiquitous language evolves through iteration. In this context iteration does not mean writing unit tests. It means that developing user stories, domain entities, features, etc. takes place in a cloud native development environment.

By developing software from its inception in a CNDE, we grow that software in the natural environment to which it will be deployed. Software behaviors are integrated behaviors. And it is hard to find a response to user interactions that does not involve a cooperation of multiple pieces of functionality working together. It can be asked why we don’t develop software functionality in an integrated manner? Instead, we break it up into individual pieces, devevlop them separately and then bring them together later in the lifecycle when we perform system integration testing.  On the face of it, this approach is not only error prone but slows down the integration of the product until later in its lifecycle. It also means that discovery of the product as a whole is delayed until QA validates it. By using a CNDE we pull the integration phase up into the development lifecycle. In fact the entire software lifecycle, including discovery and design becomes test driven. In one sense this approach can also be called the Test Driven Life Cycle.

Benefits

The benefits of this approach are multi-faceted. Not only does it promote a shared common language, but it also fosters a shared product experience. All interested stakeholders in the company can participate in experiencing the product. This leads to a highly collaborative culture. It also leads to new ideas and points of view that can significantly enhance future releases of the product. But, most importantly it goes a long way to reconciling business demands for speed and the very real constraints that exist on software development.

Upfront integration in a CNDE has the interesting benefits of evolving software more rapidly but also improving its quality. The need for over managing or hard driving the development team is unnecessary and counter productive. CNDEs and upfront integration development reduce the need for lengthy hours developing a software product. Instead, higher quality products can be produced in a shorter period of time, lowering the overall cost of development and reducing time to market.

Ideate Iterate Innovate