Do I need to spend time designing?
This article was born as a response to the article The futility of long-term design . I would like to express my opinion on this matter, to share experience, but it is not possible to put all this in the comments.
First, it is always necessary to design, even if everything is “obvious and so” in the project.
Secondly, the duration of the design and its cyclicality will depend on how complex the project is and how experienced the project executive team is.
First of all, I would like to note that designing is not only drawing up an architecture, drawing UML, SADT and other diagrams. Design begins with writing the first line of the TK, unless of course you have it. If your team was lucky to get a well-composed TK from the customer, then rejoice - the customer has done for you 30 percent of the design stage. If you do not have the TK, or it is not accurate, it is necessary to modify it in places and “add ruffles here”, then be ready to pay your analysts to shake the customer and shake out all the trifles and details of the future project.
')
So, TK is written, approved and it is necessary to decide how to proceed. And then we must continue to design, because it is necessary to analyze the requirements of the customer, to determine how the program will be divided into modules, which layers will be in the future system. Architects should work on this together with leading programmers and analysts. As a result, at the output we get the system architecture, most of the inaccuracies are clarified with the customer, architects and leading programmers already know which modules will be in the project, how they will interact, what technologies will be used for each module. After that, programmers can begin implementation.
Of course, this stage can be built in a different way: the development team opens the TK and begins to make a prototype, as they see it. In some place they discover “Oh! Here it can be taken out in a separate module - we take it out! ”. At the output, we get a prototype that works , we show the customer, we get comments, we finalize the prototype and so on with the new one.
As a result, in the second version we get an already written program, which seems to work and most likely, as it were, correctly . In the first version, most likely little is written, but then architects and leading programmers present what the system should look like. It would seem the second option is better? And no. Everything will depend on the diameter of the needle.
I will not say that I am a design guru, this is most likely not the case, but I have experience of participating in large projects.
In my, perhaps a very subjective view, it is worth starting with the writing of a prototype, skipping the design stage completely, only if the development team is very experienced and has already written this kind of system. For example, the team last year made a billing system for a local telephone service provider. And now they have been ordered a billing system for an Internet provider. It is quite possible to start here from the stage of creating a prototype, because the team is familiar with the subject area, they roughly understand how subscribers are calculated, what could be difficulties, and so on. But if the team was given a second order to write a system for selling air and railway tickets, then here I would advise you to seek the help of architects and analysts.
In the second version, different situations are possible:
1. The prototype gave the customer, everything is super, everyone is delighted! Congratulations, your team should be given a Nobel Prize. This situation is purely theoretical, I would even say, mythical;
2. Some things did not suit the customer, you saw some implementation shoals yourself;
3. The prototype is not at all correct .
In the second and third variants, it is necessary to refine the prototype. In the third, the worst version, the prototype must be thrown mercilessly and done from scratch. Again, there is an option here (with clause 3) when it will be a pity for the team to throw out a two-week job, and as a result crutches are being inserted into the project at the very first development stage (I think you shouldn’t explain what will happen to the project after two months of such work?). In the case of item 2, it is necessary either to redo it drastically, or to make changes to the existing code, but this is still editing the existing code , this is introducing new errors and wasting programmers. Isn't it easier to spend these two weeks on design and analysis, instead of writing code, which then, with almost one hundred percent probability, will either be completely thrown away, or substantially rewritten?
Moreover, if the system should be distributed, cover geographically separated enterprises (or divisions), process rather large amounts of data, if the data model contains several hundred entities from the subject area, it will take your team a couple months to create such a system. In my opinion, the construction of such systems in principle is impossible without preliminary and long-term design.
Because in order to correctly distinguish the logical layers of the system, select modules, distribute tasks between modules, you need to represent the entire system in your head. And in order to create such a picture in the head of an architect, it takes time, which is precisely in the design of the system. And the more complex the system, the more talented the architect must be (and the more he has to pay). If the system is so extensive that it cannot be represented as a whole, then it is necessary to select the most basic modules, describe them, define the interaction interfaces and the scaling model of these modules. Again, the usefulness of this stage depends entirely on the experience of the architect. Should he make the simplest mistake and in a couple of months the whole system may collapse.
I wrote a lot of words, now some veils and why I started talking about it at all:
I happened to stand at the origins of several large systems. I designed and developed one of them from scratch. This system is still evolving, it works, and it tolerates the inclusion of new modules, which were not even planned in the early stages. Now in the model there are about two hundred entities that are adequately connected with each other. In the database model there are no crutches in principle. This was laid down by the architecture - it is easier to modify correctly than to make crutches. The model of interaction between the modules of the system is also transparent and has not changed since the design. Yes, new technologies appeared, new frameworks came out, and new modules were already written using the latest programming technologies, but the architecture of the project does not change. And I have no idea how I can start writing this system without a design stage at all!
It was also possible to see how the system (already different) begins to grow into crutches, supports, patches, just because "everything is obvious here" and "what to think, it is necessary to dig!". A sad sight, I tell you.
First, it is always necessary to design, even if everything is “obvious and so” in the project.
Secondly, the duration of the design and its cyclicality will depend on how complex the project is and how experienced the project executive team is.
Creating a Technical Specification
First of all, I would like to note that designing is not only drawing up an architecture, drawing UML, SADT and other diagrams. Design begins with writing the first line of the TK, unless of course you have it. If your team was lucky to get a well-composed TK from the customer, then rejoice - the customer has done for you 30 percent of the design stage. If you do not have the TK, or it is not accurate, it is necessary to modify it in places and “add ruffles here”, then be ready to pay your analysts to shake the customer and shake out all the trifles and details of the future project.
')
And what after TZ?
So, TK is written, approved and it is necessary to decide how to proceed. And then we must continue to design, because it is necessary to analyze the requirements of the customer, to determine how the program will be divided into modules, which layers will be in the future system. Architects should work on this together with leading programmers and analysts. As a result, at the output we get the system architecture, most of the inaccuracies are clarified with the customer, architects and leading programmers already know which modules will be in the project, how they will interact, what technologies will be used for each module. After that, programmers can begin implementation.
Of course, this stage can be built in a different way: the development team opens the TK and begins to make a prototype, as they see it. In some place they discover “Oh! Here it can be taken out in a separate module - we take it out! ”. At the output, we get a prototype that works , we show the customer, we get comments, we finalize the prototype and so on with the new one.
As a result, in the second version we get an already written program, which seems to work and most likely, as it were, correctly . In the first version, most likely little is written, but then architects and leading programmers present what the system should look like. It would seem the second option is better? And no. Everything will depend on the diameter of the needle.
When to design seriously, and when to prototype?
I will not say that I am a design guru, this is most likely not the case, but I have experience of participating in large projects.
In my, perhaps a very subjective view, it is worth starting with the writing of a prototype, skipping the design stage completely, only if the development team is very experienced and has already written this kind of system. For example, the team last year made a billing system for a local telephone service provider. And now they have been ordered a billing system for an Internet provider. It is quite possible to start here from the stage of creating a prototype, because the team is familiar with the subject area, they roughly understand how subscribers are calculated, what could be difficulties, and so on. But if the team was given a second order to write a system for selling air and railway tickets, then here I would advise you to seek the help of architects and analysts.
In the second version, different situations are possible:
1. The prototype gave the customer, everything is super, everyone is delighted! Congratulations, your team should be given a Nobel Prize. This situation is purely theoretical, I would even say, mythical;
2. Some things did not suit the customer, you saw some implementation shoals yourself;
3. The prototype is not at all correct .
In the second and third variants, it is necessary to refine the prototype. In the third, the worst version, the prototype must be thrown mercilessly and done from scratch. Again, there is an option here (with clause 3) when it will be a pity for the team to throw out a two-week job, and as a result crutches are being inserted into the project at the very first development stage (I think you shouldn’t explain what will happen to the project after two months of such work?). In the case of item 2, it is necessary either to redo it drastically, or to make changes to the existing code, but this is still editing the existing code , this is introducing new errors and wasting programmers. Isn't it easier to spend these two weeks on design and analysis, instead of writing code, which then, with almost one hundred percent probability, will either be completely thrown away, or substantially rewritten?
Moreover, if the system should be distributed, cover geographically separated enterprises (or divisions), process rather large amounts of data, if the data model contains several hundred entities from the subject area, it will take your team a couple months to create such a system. In my opinion, the construction of such systems in principle is impossible without preliminary and long-term design.
Why is that?
Because in order to correctly distinguish the logical layers of the system, select modules, distribute tasks between modules, you need to represent the entire system in your head. And in order to create such a picture in the head of an architect, it takes time, which is precisely in the design of the system. And the more complex the system, the more talented the architect must be (and the more he has to pay). If the system is so extensive that it cannot be represented as a whole, then it is necessary to select the most basic modules, describe them, define the interaction interfaces and the scaling model of these modules. Again, the usefulness of this stage depends entirely on the experience of the architect. Should he make the simplest mistake and in a couple of months the whole system may collapse.
Afterword
I wrote a lot of words, now some veils and why I started talking about it at all:
I happened to stand at the origins of several large systems. I designed and developed one of them from scratch. This system is still evolving, it works, and it tolerates the inclusion of new modules, which were not even planned in the early stages. Now in the model there are about two hundred entities that are adequately connected with each other. In the database model there are no crutches in principle. This was laid down by the architecture - it is easier to modify correctly than to make crutches. The model of interaction between the modules of the system is also transparent and has not changed since the design. Yes, new technologies appeared, new frameworks came out, and new modules were already written using the latest programming technologies, but the architecture of the project does not change. And I have no idea how I can start writing this system without a design stage at all!
It was also possible to see how the system (already different) begins to grow into crutches, supports, patches, just because "everything is obvious here" and "what to think, it is necessary to dig!". A sad sight, I tell you.
Source: https://habr.com/ru/post/107670/
All Articles