Overestimate the benefits of new methods and technologies

The use of new technologies is associated with:

training costs

risks associated with the use of unproven technology

that the benefit of using better technology is less than what is usually claimed

Steve's personal recommendation: "Believe that using a new technology for the first time will reduce development productivity." And again the thesis: "There is no silver bullet."

 Make estimates in the "Zone of Improbability"

Here it is necessary to clarify what is meant by the zone of improbability. For an arbitrary project, let's imagine the following dialogue (approx. greatly abbreviated):

— Will 12 developers be able to complete the Project in 10 months?

“Yes, maybe,” we answer.

— And 15 developers in 8 months?

“Well, yes,” we answer, “more likely yes than no.”

— And 30 for 4?

- Hardly - it becomes obvious that 30 people, most likely, will not be able to work together in such a short time.

— 60 in 2 months?

- Well, this is already funny!, - you will answer ...

— And 120 developers in 1 month?

- Well, it's not funny at all. Bullying is just...

It can be seen from this dialogue that the “compression” of deadlines for a given labor intensity cannot occur indefinitely - there is a limit. So the idea of this paragraph is not to make estimates beyond this limit. Such estimates cannot be consistent. The compression limit, according to Steve, is somewhere around 25% of the nominal ratings.

In fact, there is only one way you can forego a formal approach when formulating a project goal. Only in one! This is a case of developing a small utility that solves secondary tasks, the damage from failures of which you cannot see against the background of the average cost of office supplies and toilet paper.

Before starting the story about the creation of the concept of the software development system, let me tell you about one story.

About two years ago, one of the department teams where I worked at that time had to prepare for a tender for the development of a very large and complex system for one of the leading transport companies in Russia. I was working on other projects at the time. However, after some fairly long time after the start of work, the project manager turned to me for help. The problem with the project was that none of the participants understood how the system should work. Perhaps the scale of the system and the lack of experience of the team to work with such complex projects are to blame. But the first thing I found, starting to dive into the topic, was the team’s complete lack of confidence in success. And the second is the lack of understanding of how to take on the project at all. Despite the fact that more than a month has passed, the main question remained the same: what to ask the customer to at least start work?

A reasonable level of formalism during preparation for software development must be adhered to. If you are responsible for this work, take the time to formulate the goal and objectives of the project, and as the project develops, constantly monitor whether the project is moving in the right direction, whether the goal is clear enough, whether the tasks are fully defined. Periodically review the goal setting and objectives, refining them and compressing the project's cone of uncertainty.

If you plan to develop a system for internal use that will have a significant impact on your own business, you should treat it as an investment project, with all rigor, including a high level of formalization of tasks. The stability of your business will never exceed the stability of the system you use, and for every mistake in it you will pay sevenfold