The Need for Speed

There is natural conflict that arises about business and development in an organization. Business wants a product delivered in the shortest possible time-frame. The motivation for this approach is understandable since without a product to sell the business will fail.  From development point of view, writing reams of code under duress in order to get something out the door doesn’t work. Experience indicates that code written in this way is extremely buggy and fails in unexpected ways.

The Case for Quality

The push and pull between the forces trying to accelerate development and the inclination to preserve quality are in a constant tug of war. Business wants something fast. But developers know that just hammering out code leads to bad design and bad functionality. So development always tries to resist the impulse of blindly speeding ahead. Software development is counterintuitive: Throwing more people into the mix does not make things go faster. And the shock trooper approach of putting every one in a death march, working all hours of the day and night also produces poorly functioning code. So what’s to be done? Before we answer that question we have to ask what exactly is quality?

Quality in software is not simply a set of metrics about code coverage and units tests and reports.  It is something that is inferred from interacting with the product or service. Take for example a service: Does the service respond quickly? Does it return the correct data? Does it auto scale under load? Does it respond gracefully under pressure? Another example could be the UI: Is the layout of the UI easy to use? Is the UI engaging and thematically consistent? Does it help the user navigate to solve the problem or to reach a point of sale?

None of the questions above can be answered through reports or graphs or code coverage. They can only be answered by interacting with the product. And the greater the interaction with that product helps to refine its functionality, improve its design, and promote its quality.

Usually the place where quality is tested is in system test (aka QA). And understandably it occurs at some point in the lifecycle where there is functionality to integrate. For this reason system integration occurs later in the lifecycle of product development. However today with the emergence of the cloud QA can become part of the development lifecycle as well. In Kinetic we say QA is part of the entire software development lifecycle. We call this the test driven lifecycle.

Faster Better Cheaper

The answer to the constant friction between time to market and software quality lies in an integrated development environment. And  Kinetic with its methodologies and on premise cloud creates the conditions that can reconcile these two polar opposites.

An on-premise cloud creates an integrated environment so that developers can more rapidly iterate over their code. This upfront integration helps clean out bugs in functionality as well as design that would otherwise take place in system test, which comes later in the development lifecycle. This approach serves two main purposes: It improves software quality and reduces the long cycle that exists between development and system test. It also reduces the delay that occurs in the hand-off between development and system test and the quality of software delivered to system test improves.

The question then arises – what do you do in system test? In this model, system test migrates to performing regression tests as well as performance tests on the system. It is interesting to note that performance tests, which puts pressure on the system, are not usually done on premise. They happen naturally in production. Some organizations use the macro-cloud to do integration test and performance testing. But this is an expensive approach and many organizations cannot afford to do it.

By doing performace testing as part of the development lifecycle, we are simulating production-like pressures on the system and weeding out and exposing weaknesses in the system before they get to market. This is a huge time saving, because systems that go to production with built-in performance problems take longer and are harder to fix than if they are hardened prior to launch. This is yet another example of how quality and velocity can be balanced.

It may seem counter-intuitive, but using an on-premise cloud in software development can boost both velocity and quality and deliver high value at a lower cost to an organization.

SDLC – but Better

The software development lifecycle is essentially a pipeline and as such is a design pattern. However, this pipeline as it stands today can have huge inefficiencies in it. And the reason for the inefficiencies is that software is treated as a concrete component instead of an integrated behavioral living thing. Every software component does not exist by itself, but integrates with some other software component to fulfill a user’s request.  By its very nature any software component matures through interaction with any other component. And these components togther can only really be tested when they are being used. This applies to database models, business logic, UI components, or any other software artifact used in a software product.

Design evolves through iteration; the code is hardened through iteration; systems evolve through iteration. And because of this, the approach Kinetic takes is the natural approach to building software. And by using a cloud we allow the software to evolve and grow in the native environment in which it will be deployed. The introduction of a cloud into the SDLC reduces friction, increases velocity, promotes quality and lowers cost.

Ideate Iterate Innovate