About the futility of lengthy design

About 95% of companies, and maybe even more, use the classical development scheme: mandatory design, development, testing, implementation. Rate, good or bad, you can only try something else. I tried, and this article will be purely about my practical experience.

A tale about how we designed billing

That was about two years ago. Our service was experiencing another reincarnation, and it was time to add some internal billing to heighten the control of financial relationships with the client. It did not require the functionality of full-fledged commercial billing systems, it was necessary to automate only the internal processes of the company.


We sat down to design. This was our main mistake. A real relationship model was taken and all objects from this model: contracts, additional agreements, invoices for payments, services, jobs. With this, we decided fairly quickly, and proceeded to describing the behavior of the system in ideal conditions. It seems no problems. Difficulties began when considering exceptions to the rules. With each new exception, more and more problems arose. Our model cracked at the seams, and we returned to some places again and again. Time passed, the result was, to put it mildly, not very much, so we decided to realize what we had already invented. It was hoped that in the process of implementation we would find some kind of compromise.
')
And then there was testing on the founder of the company. His words shocked me: "It will not work and it is necessary to redo it." Perplexity did not leave me long. We designed a good system that operated with familiar objects and terms used by salespeople, but we idealized it too much, having overlooked the fact that in real life everything would be unbearably more complicated. It was necessary to simplify everything as much as it could be simplified.

The first version of the "billing" did not see the light. The second was designed in about a day and still works almost unchanged. You can argue that the time to design the first version is not taken into account in the second, but in theory it should. But if you could see the real result, you would understand that the draft of the first version could be thrown into the trash without a twinge of conscience. It was a time that was almost wasted.

Design Costs

Taught by bitter experience, we spend about half a day on designing a new functional or module. This is quite enough to solve all our internal needs. We decided on objects, methods of interaction, data storage, system states, and went to make prototypes. Why think about what might initially lead the whole development to a dead end? Why break spears and spend time on creating schemes, data structures, documentation, if errors still occur? Until you have done the really working functionality, you may never notice a fundamental error in the basic logic. And such a mistake could cost you a million.

Prototyping instead of designing

Prototypes solved most design problems. You can make 80% of a certain functional and understand that only 40% did, that you need to redo both the method of data storage, and the interface, and a couple of additional modules in addition. You have not yet started the final implementation, and you already know that the vector of development needs to be changed. Could you answer these questions at the design stage? Perhaps, but most likely not. You will not understand your mistake exactly until you realize what you have designed. Only now the cost of your mistake will always be more expensive.

The prototype can be shown to customers and look at their reaction. It can be safely used in usability testing. You can do a lot of things with a prototype, which cannot be said about the design result.

In the process of prototyping, we accumulate mutations in the interface and the code. We transfer the most successful solutions to all other parts of the product. Prototypes are much faster to identify problems with the final implementation.

Financial benefits from prototyping

While you will be dirtying the pieces of paper for half a year, meticulously drawing out a hierarchical structure, your prototype competitors will have long since released a product that will solve the real problems of users. When you finish implementing the first version, competitors will end the second, and maybe the third, increasing the functions that users really need. Perhaps the product of the prototype competitors will change the market conditions or shift the emphasis, and your superproduct on hierarchy will be out of business.

Successful business!

UPD. Error correction