Let's go over the methods of software building invented in about 70 years of its existence. There are not as many of them as it might seem. But enough to be stumped.
Adage
Man is adaptive by nature. You go, for example, to the kitchen, where chicken is spinning on the grill. The scent hits the nose, and if you get hungry, you will even salivate. After about five minutes you stop smelling. The only thing that reminds of food is a piece of meat spinning behind the glass of the oven with spread wings. The smell hasn't gone anywhere, you can measure it, but the information from the receptors is blocked by the brain.
This is happening all over the place, and software engineering is no exception. We start with “wonderful discoveries” that “the spirit of enlightenment prepares for us”, smoothly move on to routine, shame-and-scrum, sprints-shmints, encapsulation-polymorphism-nationality, and, oh shit, a piece of meat is spinning in the oven, threatening to burn up to term, despite regular material stimulation above the hospital average.
In the 1960s, an inquisitive man named Richard B. Doss found that in America, saturated with Protestant workaholism, 70-80% of people work far below their ability to work. Moreover, unlike a robotic manipulator, a protein worker is able to quickly cut through it. The studies were repeated in "zero" and "tenths" with the same result. Such a situation affects health, to put it mildly, it does not matter.
The purpose of the text is not to dissuade you of insufficient productivity or to give any advice. We will only briefly go over the methods of software building invented in about 70 years of its existence.
Three ways
I will not pull the rubber, I will start with the main thing. There are only three ways to develop software. Yes, three is a good number, beautiful. So:
Top-down method . This is when at first they globally think “what to do”, then “how to do it”, and then they do it, if time is left.
Ascending way . This is when they first do it, little by little, in small parts. They think "what, yes how" only over this part, not bothering with the global and enduring.
Spiral way . We start thinking globally, but when the alarm rings, we wake up and roll out the prototype. And so several times, accumulating experience, until a solution appears according to the requirements.
Top-down development
In common parlance, all top-down methods are called “waterfalls”. If you have already been told about the existence of several pieces of ajiles, then such "simplicity is worse than theft" should arouse suspicion.
The descent of the method to the masses occurs in the 1960s, organically complementing the requirements of structured programming to wash hands before eating and use cutlery and napkins. The global task was divided into smaller subtasks, which, in turn, into even more detailed ones, and so on up to the level of a structural block that can be directly implemented in a programming language. By the way, tests for these blocks are written in parallel, hello to TDDs from the 1960s.
The Russian proverb “Measure seven times - cut once” is just about the top-down method.
In the orthodox version of the "waterfall", feedback from the customer comes only after the delivery of what has been done. We worked for a year, rolled the piano out of the bushes, it turned out "not quite right", some finishing touches are needed. Meanwhile, the customer has given birth to a long list of new features. Unaccustomed to it is a little dumb to work in such a scheme. Therefore, in a humane version, it is possible to return to the previous stage for clarification from any point, resulting in a "cascade with returns".
The advantages of the method are clear. The more thought out at the beginning, the less unnecessary work will have to be done in the middle and at the end. Multiple reinvention of bicycles, duplication of functions and mistakes are eliminated.
However, if there are a lot of functions initially, then it is not easy to give birth to the correct breakdown. We need good analysts, designers with experience in these subject areas. And even in this case, there is a risk of delaying implementation planning for an indecent period.
In the future, the method has been repeatedly improved, for example, the V-method , where the development stages on the left descent of the letter "V" correspond to the stages of tests and acceptance of the ascent on the right. The horizontal level immediately shows which project document of the contractor serves as the basis for the acceptance document of the customer.
It is clear that improvements cannot overcome the fundamental limitations of the method. That's why they are principled. This does not mean that the method is bad. He just has risks of this type. If you can fend off the risks, then everything is fine, we start thinking and enjoy the benefits along the way.
Upstream development
In fact, the ascending method is even older than the descending one. In the 1950s, both Fortran and Cobol already existed, but there was no clear idea of how to build software. Therefore, we acted in the most natural way: today we will do one thing, tomorrow another, then someday we will glue it into a third. If you need to implement several tasks, then we select the most important ones.
Sometimes the method is also called incremental, apparently by analogy with
i++
. Added a function - increment. If you want to stretch the globe onto the Mercator projection, you can also call the spiral method incremental, but more on that later. They also like to depict the method in the form of a cycle, although for
i++
the final values are not defined, so you will have to "dig" from here until lunchtime. Continuing the theme of Russian proverbs, we have a saying “turns like a squirrel in a wheel” - this is just about the ascending method.
The technique was and remains the most typical for in-house development. Their programmers have to do what the business needs yesterday. To think more globally, the 1960s saw the emergence of software houses — large design offices for the development of custom systems, including monsters such as IBM .
All this upward software building continued without significant changes until the 1990s. The main battle to match academic theories to engineering practice bypassed the safe haven because it was fought in the jungle of top-down and spiral methods.
In the 1990s, there was a powerful trend of replacing "home" programmers with external consultants. One of the reasons is the complication of technologies and specialization, which is difficult to achieve within the company for which software engineering is a non-core activity. Home software is now developed by temporary teams
In such a situation, a simple function-by-function method again seems appropriate. But working with a day-wage contractor requires more supervision than salaried full-time workers. The approach needs to be adapted, avoiding bureaucratic procedures. Indeed, in order to "issue the terms of reference" requires general planning and relevant documents, that is, vollensnolens, one would have to switch to formal top-down or spiral methods. And why does a transport company or a car manufacturer need it, for example? People just want to solve a small internal problem, calculate the salary there, or reduce the vacation schedule.
Demand creates supply, by the end of the 1990s, the so-called agile methods appeared, at the very least allowed the customer to keep his finger on the pulse, and the contractor gradually understand what, in fact, they are implementing.
What's improved:
- planning is still short, but it covers more than one function, and their group, while the term of the stage is strictly limited;
- a record of what was done is kept;
- theoretically, time should be allocated for simplifying and cleaning the code (refactoring);
- in theory, the risks of regression should be countered with comprehensive tests.
Why am I writing "theoretically"? In practice, when the budget is limited or in time trouble, these two points are sacrificed in the first place. The "holy cow" in ajiles is not the quality of the code, as the authors intended, but the deadline for the next function.
Duplication of code, unnecessary complications, postponed "for later" ineffective implementations - if you do not clean up what was done earlier, then the technical debt grows. The later the debt is repaid, the more you have to pay in the end: time, man-days, mistakes, failures, slow work, etc.
After some 10-15 years, the authors of the "Ajaila Manifesto" began to sound the alarm: "Guys, what are you doing, we meant something else." They are somewhat correct, bottom-up development is so simple and so compelling that all these additional procedures seem unnecessary.
Let's summarize what's good about bottom-up development. First of all, the entry threshold is sharply reduced. To start from scratch does not require expensive analysis and design specialists with experience. Although the entire construction can last indefinitely, the first barracks are being erected soon, and you can begin to settle down in them. It is easier to manage the process, control points and local goals are transparent.
The problems, as in the case of "waterfalls", are fundamental. It is easier to manage the process, but almost impossible - the end result, since it is not clearly recorded anywhere. The risks are passed on to the customer: let the product owner think he has a big head. If the team copes with the technical architecture with experience, tests and refactoring (up to a certain threshold of complexity), then the functional architecture is bad. Simplification of the problem statement, the very "refactoring", now the domain model, would help to get rid of the fancy and expensive code to maintain, but there is no one to make it. And there is no model, to be honest, all the semantics are in the heads and in the code.
But there is no reason to be upset, remember about the most disastrous sprint in world history: 5 days of creation and one and a half billion years of continuous refactoring.
Spiral engineering
The aforementioned “waterfall” limitations became clear back in the 1970s, after the massive introduction of appropriate methodologies such as SADT / IDEF . At the same time, we worked on bottom-up methods on “home” projects with other problems, which created a feeling of some dead end. Therefore, the researchers puzzled by the problem (primarily Barry Boehm ), scratching their turnips, issued by the mid-1980s an updated vision of the software building process in the form of a spiral .
The logic of the "spiral" reasoning is approximately as follows. Yes, as the complexity of tasks grows, we spend more and more time on analysis and design, the risk of errors at this stage is growing. But implementing individual functions without a general plan, we risk making mistakes no less, and we end up with ineffective or simply incompatible parts. Therefore, we will leave alone the "holy cow" - design, but a) we will limit the time frame for it and b) we will rigidly check the decisions made, rolling out a full prototype.
Point "b" is very important. With bottom-up development, you also constantly produce something, bug fixes, new features. But it will work if the system is already in operation and under maintenance. And if not? Imagine a customer wants a train traffic control system, and in a couple of weeks you show him screens for entering information about the rolling stock and a timetable simulator. Not seriously.
The prototype should include most of the functions, even if not fully implemented or even with "stubs". From the full prototype, respectively, we get full feedback: here they screwed up, did not understand the essence of the requirements, they did not take into account the operating environment, there the output format does not match the input format, etc. With this precious feedback, we begin the second round of the spiral, reasonably believing that the chance to bring the next prototype to the level of a finished product is high. For medium-sized systems (up to a million lines of code approximately), two or three turns are enough.
From what has been said, it is clear that attributing the spiral to incremental methods is as ridiculous as whales are to fish, although both have tails.
What's good about the spiral? We drastically reduce the risks of rolling out to the customer instead of a product, frankly getting on, but at the same time we do not sacrifice design. That is, the global vision of the situation remains, the end result can be managed by calculating the budget and profit. Everyone, client and contractor, can see the light at the end of the tunnel. The customer, if he is serious in his intentions, will not bawl either: "Why are you putting on my tail, then slipping my trunk, show me the whole elephant!" At each turn, the entire elephant is visible.
However, in comparison with rising software engineering, it is impossible to manage a platoon of programmers-technicians without analysts and designers, and you will have to explain this delicate moment to the customer in justification of a higher price. After the design stage of the first round, the specialists do not stand idle, but continue to bite into the task, waiting for feedback, but at the final round they will most likely not be needed at all. The length of the coil can be up to several months, but usually it costs two to three. It doesn't look like a weekly sprint extreme, but neither does it look like an annual expectation of a product. It is also not easy to choose when, at this stage, “it's enough to design” and it's time to start laying bricks.
The most famous and successful implementation of the spiral technique - MSF(Microsoft Solution Framework). Microsoft later had a cropped version, sharpened for bottom-up methods, and marketed as MSF for Agile for relatively small projects and teams.
Instead of an epilogue
Grandpa Brooks outlined four types of software that people build in his bestselling book .
The picture shows that at some point you can stop “just writing a program” and “for an exorbitant price” want to make it either a product (something that is supplied to many different clients), or a complex (something that consists of many programs and seamlessly integrates into the customer's environment, including equipment). And if "writing a program", by and large, can be any of the soft-building methods, then your excellent plans for further development can be disrupted by the shortcomings of top-down and bottom-up methods.
In conditions when the human resource of programmers-technicians is excessive with a shortage and difficulties in hiring designers and analysts, instead of a horizontal organization (“systems engineers” make a platform for “applied engineers”), they start using a vertical one, where each team implements its functions on the basis of its own bicycles. From the point of view of management, the second method looks simpler, but only until the moment when a horizontal “architecture” command is introduced, which reduces the risks of the same repetitive mistakes through long persuasion and agreement.
On this, perhaps, we can stop, for the initial orientation in the space of information should be enough. There are keywords and some links in the text, so the curious can dig the topic further.
Original text on the site "Mechanics of software engineering"