3 ways to develop

Development Aimed at Creating Garbage

A popular development process in some large firms is Development, Aimed at Creating Garbage, or abbreviated as RNSM. RNSM relies on the belief that the only thing needed to get money is a good idea. Obvious nonsense, but it is a support for people with a lack of imagination. This theory says that an Idea is a rare, valuable and unique thing and the whole trick is to catch it.

The main product of PHCM is meaninglessness, written on such “valuable” ideas: concepts, graphics, design descriptions and other products created for the sole purpose - to be thrown into the basket.

It works like this:

• Creative Guys come with a long list of “features A and B that we can do in our product”. An incredibly detailed list of this and that that our future Great Product could do. What are they good fellows that came up with all this! Well, now, when the main (creative) part of the work has already been done, there remains only a question of technical implementation, but this is not difficult!
• Managers and their consultants pass on brilliant ideas to designers and architects who write tons of specifications. At this stage, a dozen basic ideas turn into several hundred detailed requirements. For a product that will change the world.
• Specifications are passed to developers, who are somewhat ... surprised, cautiously asking, and to whom, ..., did it occur to ... write? They begin to explain why it is difficult to do something, but something is impossible at all, but ... The train has already left. The architecture is approved at the very top, and in fact - who are these developers to argue with the Creative Guys and their highly paid consultants?
• Developers are returning to their jobs, humiliated and doomed to build a giant "creative-and-elegant" pile of garbage. This work turns the mind, because the theorists from above have absolutely not thought about the nuances of practical implementation. “Elementary” and “minor” changes can take weeks. The project starts to lag, managers click on developers, free evenings and weekends disappear.
• In the end, something that somehow pretends to be a working product is released. It is awkward and fragile, complex and ugly. Creative Guys are calling the developers incompetent mediocrity and paying their consultants even more money to hook a bow on this pig, and now it looks as if it is getting a little better.
• By this time, managers begin to try to sell all this horror, and suddenly (surprise-surprise!) It turns out that nobody needs it for three hundred years. At this point, the most important thing is not to fall into the mud with your face and ... throw out a million dollars for an advertising campaign! You have to pay almost to convince people to use this product. Ah, this stupid, backward and ungrateful market!
• After a year of intensive marketing, the product is still unprofitable. Moreover, this whole year he was pursued by catastrophic failures and negative reviews in the press. The company quietly lowers it into the ballot box, dismisses consultants, buys a competitive product from a start-up company living in a nearby garage and releases it as "Version 2.0". Hundreds of millions of dollars are thrown into the trash.

')
In the meantime, another Visionary from the top management is drinking an extra glass with the marketing guys and the Brilliant Idea comes to his mind ...

Development Aimed at Creating Garbage could be a caricature if it had not happened so often in life. Something like 19 out of 20 products marketed by large firms are failures (yes, 87% of statistics are taken from the ceiling). The remaining 1 out of 20 is successful for some completely random reasons, such as very bad competing products or a new market.

The main conclusion from the application of PHCM is easy to make, but difficult to accept: ideas cost nothing. With no exceptions. There are no "brilliant ideas." Anyone starting a discussion with an exclamation “oh, and we can do THIS!” Must be beaten by the surrounding people with all the passion and energy that they took for Jehovah's Witnesses to ring at the door. All these Creative Guys with their “brilliant ideas” look like a person sitting in a cafe at the foot of the mountain, drinking his hot chocolate and explaining to others: “Hey, I have a great idea - we could climb this mountain! And build a cottage on top! With two saunas! And the garden! It can be connected to solar panels! Dude, that's cool! What color will we paint it in? Green! No, blue! So, go and build it, and I will stay in this cafe and draw a couple of graphs for our project! ”

The starting point for a good product is to collect real problems from real people. The second step is to calculate whether it is reasonable to solve these problems economically. Good solutions to real problems - this is a successful product. “Good,” among other things, also means “cheap,” which means “simple.”

And now, after defeating the Dragon of Total Inappropriateness, we will attack the Demon of Complexity.

Development Aimed at Creating Complexity

Good engineers and small firms are theoretically capable of creating decent products. But the vast majority of products are still too complex and less successful than they could be. This is because the teams of specialists are persistently implementing a development process in my work, which I call Development aimed at Creating Complexity (RNSS).

It works like this:

• Managers rightly find interesting and important problems with the real economic effect of solving them. At this stage, they are already one step ahead of the companies practicing PHCM from the previous paragraph.
• The development team enthusiastically begins to build a prototype system, and then the basic functionality of the main product. Everything goes according to plan, the work goes on, things are made logical and elegant.
• By this time, management comes with even more interesting and important issues. Yes, they are harder to solve (something will have to be redone in general), but if we do this, we will be two more steps ahead of the competition, right?
• Developers do what developers have to do - develop. Develop, develop, develop and once again develop. Managers come with their interesting and important tasks again and again. And the developers are developing again and again. To get in the end an ideal, solid, massive, HUGE COMPLEXITY.
• The product enters the market, the market scratches turnips and asks, “What, is this all that really needed to be done so difficult?”. People start using the product somehow, spending their time and money to sort out its unimaginable complexity, but what if there are no alternatives?
• Management receives positive feedback from major customers - their management believes that if everything is so difficult and you have to spend so much time on training and use, then this is definitely a good product (?!).

RNSS is characterized by teams of people who are furiously and fanatically solving private tasks, not needed by 99% of users. RNSS products are bulky, ambitious, complex and unpopular. Many open source products came into being in an effort to get a simple solution where there was only a difficult one. For some engineers, it is incredibly difficult to stop in an effort to expand the functionality of the product "in case someone suddenly needs this." They want to do good to people without thinking about whether they need it and whether these people exist anywhere in the world.

A good example of RNSS is Bluetooth. This is a complex, contrived set of protocols that users hate. It continues to exist thanks to a massive package of patents that are simply impossible not to violate, creating an alternative. Bluetooth is ideally safe, which is close to meaningless for a protocol of such a short range. At the same time, it suffers from a lack of a standard API for developers, forcing everyone to invent a non-compatible bike with anything in their application.

On the IRC channel, #zeromq Wintre once wrote how furious he was when he discovered many years ago that the XMMS 2 audio player has a good plugin system, but cannot play music.

RNSS is a swamp, in which developers and architects boil in their own juice, invent problems themselves and heroically solve them themselves, not at all caring about how much this is all in demand outside the boundaries of their imaginary world.

The main conclusions from the RNSS are again easy to make, but difficult to accept:

• Creating a product that you don’t need right now is pointless. No matter how smart and talented you are, if you are doing no one needs anybody about which no one asked.
• Problems come in all sizes. Some are simple, others are not. Strange, but often the solution to simple, fiddling problems is just what people need. On the other hand, developers are not interested in working on trivialities and trivialities; give them Challenge, Problem. If you let the development take its course, developers will work on exactly interesting for them, but not the fact that the tasks are useful to users.
• Engineers and architects like Architects, Patterns, everyone there, to generalize something, and then to optimize, and there to show off with a hack - and all this inexorably leads to an increase in complexity. It is critical to have a leverage on such things. This may be, for example, a hard deadline, forcing the developer to make a small, simple solution that works "here and now", instead of the ingenious and the general, which will never be completed.

Development Designed to Create Simplicity

And finally, we got to a rare, but all the more valuable way to work - Development, Aimed at Creating Simplicity, or RNSP. It begins with a simple thing: you need to realize that we do not know what we want to build, before we begin to do it. Starting with Brilliant Ideas and plans for flexible scaling across thousands of servers is not only pointless, it is rather a direct obstacle to a neat basic architecture. The real problems are really hidden in the fog and the only way to dispel it is to start moving, to explore how you explore the hidden map in a computer game. At the first stage, you need to be fast, mobile, in one word move - and so far it’s not so important where. Only having explored a certain area, it will become clear where to go next.

RNSP works like this:

• We collect a lot of interesting problems in some area and arrange them in ascending order - from simple to complex, trying to find some common patterns.
• We take and solve the simplest, elementary problem, and we do it in the least expensive way - “patch”. Each patch solves exactly one problem, and in exactly one minimally costly way.
• We are introducing a single patch quality metric: “Can it be made even easier while still solving this problem?”. The complexity can be measured in the amount of information that the user will have to learn (or guess) to use the patch. Less is better. An ideal patch solves a problem without requiring any knowledge or skills from the user.
• Our development process begins with a patch that solves the problem “we need proof of concept” and develops into a powerful product consisting of hundreds or thousands of patches that complement and correct each other.
• We do not do anything that is not a patch. We build the rules of the development process in such a way that each task is solved by one patch that solves this and only this conscious and described problem.
• We build a “supply chain” of tasks to which users add their problems, and developers solve them. This chain has a good “stop mechanism”, which does not allow developers to fly away into the transcendental distances on the wings of their imagination - and try to do this when there is a specific living person waiting for a quick solution to the problem.
• Developers have the right to work on any projects and provide patches to any component. No one owns the project individually - there is a “main” repository with its own formal criteria for accepting patches, but if someone doesn’t like them, anyone can make their own fork. The same project can have competing forks, encouraging each of them to develop better.
• The project provides a set of documented interfaces, allowing other components (clients, plugins) to use them. Creating a good API is a way to get a lot of satellites, build an ecosystem and conquer the market.
• We derive the task supply chain to external users and customers and provide a cycle of frequent releases, so that a user problem can come to us from the outside, be analyzed, evaluated and corrected with a patch in just a few hours.
• At every moment since the first patches, our product is ready for delivery. This is important because a significant portion of the patches (10-30%) will be incorrect and only by giving users access to the product we can understand what went wrong and needs to be fixed.

RNSP is a reliable way of finding optimal solutions to the most significant problems in an unknown subject area. You do not need to be a genius to apply RNSP, you just need to see the difference between the aimless wandering in the fog and the activities to dispel this fog, as a result of which the really important problems appear.

Some people point out that such an algorithm has its drawbacks. Walking in small steps, we can get stuck at the “local peak”, having missed the opportunity to jump to the top of the ideal. But this, nevertheless, is how everything happens in real life: we take small steps forward here and there for a long time. There is no "reasonable plan for life." We reduce the risk of getting stuck at a local peak with a wide coverage of the problems at hand. The theory says that this is how innovations appear, so it’s better to use this more or less scientific approach than to hope for success or solve all the problems with some kind of magic.

As soon as you grasp the full power of this approach, the power of collective thought and the wonderful infinity of improving your product, you also realize why some companies and products get stuck in a swamp of disastrous prospects. They simply do not have a variety of thinking, approaches, collective intelligence and imagination for the proper exploration of unknown subject areas and markets. When Nokia killed its open projects, it cut the throat to itself.

A good architect with a good team can use RNSP to build world-class products. To get the maximum benefit - RNSP should be used constantly, day after day, working out the developer scent on the problems of illogicality. We often lose sight of any minor inconsistencies, but a good architect sees them and is able to take them as a chance to make the product better. The essence of this type of building software in a non-stop (albeit not great, but constant) approximation to the ideal in the use of the product.

In the world of opensource, we do all this work in plain sight. There is no "well, let's open the code" moment. Products that decide to open the code only at some stage take away from the user the opportunity to trace the whole exciting story from the very beginning, to create a community around their product from the moment of its birth.