6 reasons why you should not write functional specifications
A small essay from the book “ Getting Real ”, written by 37signals. The original can be read here .
The specification is an abstract document, in most cases having nothing to do with the finished software product. Why? We are happy to explain:
1. Specification is fiction
')
She has nothing to do with reality. The application becomes real when the developers write the code, the designers draw the interface, and people begin to use the finished product. Specification does not bring the project to completion - it is nothing more than words on paper.
2. The task of the specification is to please everyone.
Any specification promises everything at once, and tries to make everyone happy. This is a laudable, but completely useless approach. The specification never deals with finding complex trade-offs and choosing the best options, and developing applications cannot do without it.
3. Specification is only an illusion of agreement
The many certifying signatures under several pages of specification are not an agreement. Your team read the same text, but most likely everyone understood it in their own way. And this will surely emerge in further work. “Wait, I didn’t mean it at all!”, “Stop, I understood it completely differently!”, “No, no, that's it, and you all subscribed to it” You know how it happens.
4. The specification forces you to make the most important decisions when you least know about the project.
Least of all about the project is known at the very beginning of work on it. The longer the project lasts, the more you learn about it. So why should you make the most important decisions without even getting started?
5. Using specifications results in fouling of unnecessary functionality.
At the time of writing the specification does not limit you, except for your imagination. There is nothing easier than to add a paragraph of text or add another item to the list. You don’t have to add anyone's idea to the project, just to make the author pleasant. What do we have in the end? Your project begins to lead not common sense, but paragraphs of the text and numbered lists. This is how the websites with thirty horizontal tabs in the navigation bar are born.
6. Specification does not allow you to develop, change and evaluate the distance traveled.
Any item specification is discussed three times and secured by a bunch of signatures. Even if during the development process you realize that some of the features are useless, you will not have a way back. The existence of a fixed specification contradicts the fact that requirements may change during the creation of an application.
What should be in place of the specification? Start with a simpler document that brings you closer to a working prototype of an application. Write a short text about what your product is doing. Express your thoughts in a free form, not adhering to any templates. Limit yourself to one page and don’t spend more than one day on this task.
After that, proceed to building the user interface. That interface will serve as a substitute for the specification. Start with simple sketches on paper, and then format the interface in static HTML
Before you start writing the main application code, make a prototype of the interface that can be viewed, clicked and discussed. Try to look at your product as soon as possible through the eyes of the end user.
Forget about fixed specifications. They force you to make the most serious decisions in the early phases of a project. Try to do without the specification in its classical sense, and it will be much easier for you to change the requirements and remain flexible.
Finally, a short quote from Linus Torvalds:
The specification is an abstract document, in most cases having nothing to do with the finished software product. Why? We are happy to explain:
1. Specification is fiction
')
She has nothing to do with reality. The application becomes real when the developers write the code, the designers draw the interface, and people begin to use the finished product. Specification does not bring the project to completion - it is nothing more than words on paper.
2. The task of the specification is to please everyone.
Any specification promises everything at once, and tries to make everyone happy. This is a laudable, but completely useless approach. The specification never deals with finding complex trade-offs and choosing the best options, and developing applications cannot do without it.
3. Specification is only an illusion of agreement
The many certifying signatures under several pages of specification are not an agreement. Your team read the same text, but most likely everyone understood it in their own way. And this will surely emerge in further work. “Wait, I didn’t mean it at all!”, “Stop, I understood it completely differently!”, “No, no, that's it, and you all subscribed to it” You know how it happens.
4. The specification forces you to make the most important decisions when you least know about the project.
Least of all about the project is known at the very beginning of work on it. The longer the project lasts, the more you learn about it. So why should you make the most important decisions without even getting started?
5. Using specifications results in fouling of unnecessary functionality.
At the time of writing the specification does not limit you, except for your imagination. There is nothing easier than to add a paragraph of text or add another item to the list. You don’t have to add anyone's idea to the project, just to make the author pleasant. What do we have in the end? Your project begins to lead not common sense, but paragraphs of the text and numbered lists. This is how the websites with thirty horizontal tabs in the navigation bar are born.
6. Specification does not allow you to develop, change and evaluate the distance traveled.
Any item specification is discussed three times and secured by a bunch of signatures. Even if during the development process you realize that some of the features are useless, you will not have a way back. The existence of a fixed specification contradicts the fact that requirements may change during the creation of an application.
What should be in place of the specification? Start with a simpler document that brings you closer to a working prototype of an application. Write a short text about what your product is doing. Express your thoughts in a free form, not adhering to any templates. Limit yourself to one page and don’t spend more than one day on this task.
After that, proceed to building the user interface. That interface will serve as a substitute for the specification. Start with simple sketches on paper, and then format the interface in static HTML
Before you start writing the main application code, make a prototype of the interface that can be viewed, clicked and discussed. Try to look at your product as soon as possible through the eyes of the end user.
Forget about fixed specifications. They force you to make the most serious decisions in the early phases of a project. Try to do without the specification in its classical sense, and it will be much easier for you to change the requirements and remain flexible.
Finally, a short quote from Linus Torvalds:
“... They are practically useless. I have not seen a single large project in which the specifications fully corresponded to the reality and at the same time really helped the developers.
But I saw a lot of failed projects that blindly relied on specifications. Believe me: specification development is the worst way to build applications, since it means that your project will be done only according to theory, without looking at reality. ”
Source: https://habr.com/ru/post/113077/
All Articles