Confidence is what you’re developing

In this short article we explain our vision of the difference between 2 polar approaches in the software development. It’s especially vital for building commercial products nowadays, when the competitors are not dreaming, and the time is ticking with double speed.

Okay, you want to create something serious for your business or, perhaps, you get a great idea for the software application that may become a real breakthrough. No problem, you can always find people to help you with it. In fact, it’s possible to find a lot of companies, teams and single people who can develop the software you need with proper quality. But now we’re not going to focus on the problem how to choose the right people, however. Rather, we highlight the question of your being satisfied with the result.

The question is how to be confident that the software you’re developing will reflect exactly what you have in your mind. Will the house you’re building be comfortable for living?

The complexity of the problem is such that in real life you can’t solve it until you have the house built or at least until you imagine your living in the house with the help of fantastic 3D models of the rooms. Such 3D modeling may give you some perception of what you’re going to have in the end. Virtual models designed in the right way may demonstrate you quite tangible results as if the house was real.

Of course, you can’t immediately come in, live in this building and try everything to see how it works for you or your customers. So, there is always a risk that what you get will not be 100% comfortable, not even 80% comfortable. But this is a house and even with 80% comfort it may be sold and be considered suitable for living.

In the software market you don’t really want anything that will meet your expectations less than with 100% conformity. You want to be sure that the final product exactly makes the reality of the idea you had in your mind, including all the small details you even did not think of in the beginning, the big idea taking your entire mind. This is damn right especially for a commercial product targeted at millions of people. If they don’t like any specific features, or some of their needs are not met, they will simply refuse the product.
You may say it’s a usual risk for software development projects that the final product is not as good as you imagined. At this point you’re right and wrong at the same time. Everything depends on the way you choose to build your software product.

Remembering construction analogy, you may want to start with the complete architecture and engineering phase. This is an established approach. You hire architects to try to imagine living in the house according to the design sketches. Then you hire engineers to convert what you have in your mind into the specifications for construction. You will be lucky if they annoy you with additional questions so that no small detail is missing. As a result of their work, you get volumes of documents that are hopefully good enough for constructors. Then the construction team builds something based on the documents.

Frankly speaking, do you believe it’s possible to describe your inner feelings in words and forecast the real experience looking at pictures?
The answer is likely to be “no”. You can only hope that the design and documents give a really good approximation to what you were thinking about. There is no other way to build a house.

Software development being a good son of engineering has inherited this model. It has been dominating since late 70s and has been considered to be the only way to do things.

We are speaking about a well known Software Architecture and Specification Phase. You can read millions of books about it full of magic words like UML, RUP and so on. There is a whole generation of scientists who built their careers on this methodology.

In brief, during the Software Architecture and Specification Phase you, together with software designers, try to define business goals and corresponding system requirements, figure out acceptable parameters, define the level of usability, create the system architecture and database structure, build the strategy and the plan, put together the task plan, make up the time and resource allocation table. It takes about the same amount of paper as the house construction mentioned above.

In terms of time, it may take several months to go through this phase and only in the end you may have a picture of where you are going to and what it will cost. Finally, after spending months on it, you have the final figures of when something described in the documents is going to be completed. However, you still can not be sure if the final result will 100% fit your and your customer’s needs. And you still have no idea of what you’re really building as you haven’t seen or touched it.

Indeed, all you have done is spent several months talking about the project – about your vision of it, how you see your customers imagine it, how you feel their feelings about it and all that stuff. The fact is that you spent months in the assumption that you can put your mind into the paper that will be clear and transparent to others.

Was it really worth it? The papers are an important, but just one chain link in the information workflow. First you put your thoughts into the documents, then this information should be read and understood by others. Do you really need this extra step to communicate with the developing team? It’s pretty obvious that part of the information will be lost somewhere between you, papers, and developers.

To make the matters worse, at the end of this process you find yourself exhausted, but still start developing the software according to the specification you just finished. In fact, at this point you’d better go on a long vacation and get back when everything is done in strict accordance to the specs. It would be wise of you to “sit back and relax” until they finish, because you may wake up one morning with a good idea in mind and a great desire to implement it. But you can’t actually change anything. Well, of course you can, but it may require new months to add this small detail into complete software design seamlessly.

This is how it works. Having done your part you’re hopefully still the number 1 who put it into the market, and pray that you’ve managed to guess your customer’s ideas about the product.

Amazingly, most of the software is still built using this cut and try method. Months are still wasted before any real work begins. The process lacks flexibility after you started the development. The real tangible results appear only in the end, when it may be too late because your competitors have overtaken you and the world has changed.

The good thing is that software development differs from the house construction in its nature, which should be used for business purposes. The biggest “wow” comes out of the possibility to build something like a room, try to live in it and recognize whether it’s good enough for living and corresponds to what you thought. This can be done before completing the house, and at any time you may rebuild any room if you find it not suitable enough.
Futuristic as another method may sound, it can demonstrate you the first tangible result in a couple of weeks. You can immediately see how everything works and decide what to do next based on the business priority. Then in the course of months you can see the software versions presented to you and your customers every 1-2 weeks. You can enjoy this big advantage leaving your competitors far behind.

The model is based on the sound sense. You describe the software components in terms how they should work for the end user. These user ideas are prioritized according to the business importance. For each idea developers create test cases to make sure everything works right, and you see it work immediately instead of only after the end of the testing phase. Another advantage is that the work starts right with the most important component which may give you immediate results.

Software is usually designed on the iterative base, so you control the progress on a daily basis and work out further plans, while the developers keep working mad. The biggest advantage of this approach is full flexibility of changing anything you like or adding any new details during the production phase. This is a very attractive feature for any commercial software.

Such method is a step by step approximation to the required software based on human rationality and wisdom. You don’t let go any information communicating with the production team, you don’t waste any time creating unnecessary papers, and you don’t wait for months before seeing any tangible results. You actually can be 100% confident that you launch it fast and the final result exactly reflects your ideas.

All you need to do is communicate with the development team as much as possible and cooperate with them during all the project phases. Communication and Cooperation lead to Confidence.

Apparently this approach doesn’t need to have fixed timeline and budget; you can afford to be creative during the whole process; and the final feature list may differ a lot from what you started with. Your money is spent the most effectively as you pay for the enormous flexibility the approach provides and for the quickest time to launch the product first. You pay for the total confidence in the final result. Isn’t it what you (and we) are really looking for?