March 19, 2019 at 12:49Why does business need good code?
In the field of software development, there are often theses like “ Nobody cares about your code ” (translation - “ Your code does not interest anyone ”), “Code is just a tool” and situations of complete misunderstanding on the part of business why we should take time and money for some kind of "refactoring" of the code that already works.
I want to tell you what the “emphasis on characteristics” can lead to, instead of caring about the quality of the code, and why not only programmers need good code.
The main thesis, without which the current article, in principle, would be meaningless:
What has been happening in the programming world for decades, for the sake of which more advanced languages, paradigms, approaches are created, for which they distinguish various templates and take care of the code design are, in fact, two things - Increased development speed and easier support for the codebase (which is essentially the speed of developing new functionality).
And these are the things business needs.
Of course, one can argue that they themselves need the methodologies that increase the efficiency of programmers' labor in order to sell their work more expensive, being able to do more per unit of time, but because the situation when programmers order a large finished project right away without the need for further support is very It’s rare, and usually the functionality is ordered gradually, at the start of the project you will not feel the harmful effects of poor design, it is rather an investment in the future.
There is an image from Martin Fowler ’s blog on this subject , showing the speed of introducing new functionality into a project depending on its time of existence (i.e. how large it is).
The horizontal axis is the project lifetime, the vertical axis is the aggregate functionality.
The red line illustrates the development speed of a project with a good design, and the blue line illustrates a project that is written without any restrictions in the form of requirements for the quality of the code.
Thus, if you think that your application is doomed to failure and will not develop, or is preparing exclusively for some upcoming event, you do not need to think about the design of the system. In the opposite situation, a good design is likely to pay off, and pay off many times.
Sometimes you can hear the opinion that at the start of a project you don’t have to think about the quality of the code and rewrite it again after a successful presentation to clients / investors, but in the vast majority of cases this is a mistake of starting projects, and the easiest way to earn technical debt for years to come.
A software company does not use code as a tool. This is the main product of the company, it is the final code of the program that determines its quality, speed, compliance with the requirements for functionality. It cannot just be taken and completely replaced without incurring temporary and material losses, as could be done with Computer / IDE / Development Methodologies, which will essentially be tools for creating a product.
About the “Emphasis on Characteristics”
In the article to which I referred, the following thought was voiced: you need to communicate with the customer / Project Manager at the level of readiness of the project, and the following example was a contrast:
So here. There is one difference because of which it cannot simply be projected onto the situation with the support of a software product - all these layers and brushes in Photoshop become unnecessary to anyone right after the result of work (pictures), and just the same are a tool to achieve the result , not the final product.
Thus, when drawing up the requirements for the final pictures, the customer can not worry about what will be used in the process. In the case of software, if the customer (business) will demand only functionality from the application, he runs the risk of getting exactly what he wanted - new functionality, but there was no question that it would need to be maintained and developed.
Unfortunately, this is a fairly common problem at outsourcing, when a company sells only the time of its developers, and customers cannot objectively evaluate the quality of the system, and the time it takes to solve its problems. When the cost of changing the code increases exponentially, it will only benefit the company itself to the outsourcer - more human hours can be monetized, and the company ordering the product will already be on the hook - it’s too late to rewrite the bulky and inconvenient system, since it requires huge investments and stopping the delivery of new functionality that cannot be allowed.
For all the time that the article was in draft copies, I thought a lot whether this item should be included in it, but after a little observation of the priorities of candidates who are looking for work, I realized that this moment is really important.
Code is something that a programmer will have to work with every day, his creative product, what he creates, but creates not just one, but in a team, and often not from scratch. He needs to accept the already existing part of the project, develop it based on the functionality that was written before it. An employee will most likely be unpleasant to work in a product that is created poorly.
In the first place, in my opinion, is the team working together on the project. The quality of the resulting product directly depends on how the team work is built, on the internal rules and the requirements established inside it.
In second place is technology. A thoughtlessly chosen or inherited inconvenient framework, outdated and poor-quality tools, libraries nailed to the project place with all their crutches and bugs that you have to put up with, and the lack of people with sufficient competencies and time to eliminate legacy approaches can easily scare away new potential workers. In addition to the reasons stated above, this is also a smaller number of prospects and opportunities for the development of programmers, because instead of studying modern and most effective tools, it is necessary to develop props to adapt solutions to current problems due to historical reasons.
Unfortunately, the requirements for real applications can rarely be formed at 100%, and do not require revision during development. Moreover, the situation is almost impossible when the project does not have to be adjusted to new requirements after launch. The business expands, develops, requires functionality that was not discussed before, enters new markets.
It is almost impossible to build an architecture that is ideal and thought out to the smallest detail in such conditions, and, often, there is no need, because its cost in this case is unreasonably high for the initial stage of the project.
Certainly, writing good code should not be a headache for those who order software from programmers, and it is unlikely that anyone who can not write it can check it.
Nevertheless, a company developing a software product, if it wants to make it qualitatively, must understand that such a significant part of the product as its source code directly affects its success, and such things as refactoring the source code and modifying the architecture to the new requirements should also be a budget, time should be allocated to programmers. If someone is interested in the quality of the product, of course.
However, the IT industry is developing, products, companies, tools are developing, users are becoming more selective, competition is increasing, and there is hope that the future will still be with high-quality products.
In fact, the topic of the article is, of course, very controversial.
The above graph does not answer the question at what point in time the design of the system begins to pay off.
Technical debt for that and debt, which allows you to get a little more time now and give it back with interest later, and its main problem is extremely simple, and strongly resembles a similar phenomenon in the economy, is the inability to pay off debts and the inability to accurately estimate future income.
The quality of the code is also a very subjective thing, and, unfortunately, practically unformalized, otherwise the programmers could already be replaced by robots.
In any case, the most important thing is to achieve competent compromises and find that middle ground, which will allow us not to drown the project in the pit of technical debt in pursuit of functionality, and not to give up an interesting niche to competitors, doing system design instead of functionality.
I want to tell you what the “emphasis on characteristics” can lead to, instead of caring about the quality of the code, and why not only programmers need good code.
Support
The main thesis, without which the current article, in principle, would be meaningless:
What has been happening in the programming world for decades, for the sake of which more advanced languages, paradigms, approaches are created, for which they distinguish various templates and take care of the code design are, in fact, two things - Increased development speed and easier support for the codebase (which is essentially the speed of developing new functionality).
And these are the things business needs.
Of course, one can argue that they themselves need the methodologies that increase the efficiency of programmers' labor in order to sell their work more expensive, being able to do more per unit of time, but because the situation when programmers order a large finished project right away without the need for further support is very It’s rare, and usually the functionality is ordered gradually, at the start of the project you will not feel the harmful effects of poor design, it is rather an investment in the future.
There is an image from Martin Fowler ’s blog on this subject , showing the speed of introducing new functionality into a project depending on its time of existence (i.e. how large it is).
The horizontal axis is the project lifetime, the vertical axis is the aggregate functionality.
The red line illustrates the development speed of a project with a good design, and the blue line illustrates a project that is written without any restrictions in the form of requirements for the quality of the code.
Thus, if you think that your application is doomed to failure and will not develop, or is preparing exclusively for some upcoming event, you do not need to think about the design of the system. In the opposite situation, a good design is likely to pay off, and pay off many times.
Sometimes you can hear the opinion that at the start of a project you don’t have to think about the quality of the code and rewrite it again after a successful presentation to clients / investors, but in the vast majority of cases this is a mistake of starting projects, and the easiest way to earn technical debt for years to come.
Code is not a tool; code is a final product
A software company does not use code as a tool. This is the main product of the company, it is the final code of the program that determines its quality, speed, compliance with the requirements for functionality. It cannot just be taken and completely replaced without incurring temporary and material losses, as could be done with Computer / IDE / Development Methodologies, which will essentially be tools for creating a product.
About the “Emphasis on Characteristics”
In the article to which I referred, the following thought was voiced: you need to communicate with the customer / Project Manager at the level of readiness of the project, and the following example was a contrast:
Imagine that the designer will begin to tell you about the layers he used in Photoshop, about how many objects he has there, what gradients are used on which brushes, and what cool animation scripts he wrote. It doesn’t interest you. Are you interested in whether it is already possible to take pictures.
So here. There is one difference because of which it cannot simply be projected onto the situation with the support of a software product - all these layers and brushes in Photoshop become unnecessary to anyone right after the result of work (pictures), and just the same are a tool to achieve the result , not the final product.
Thus, when drawing up the requirements for the final pictures, the customer can not worry about what will be used in the process. In the case of software, if the customer (business) will demand only functionality from the application, he runs the risk of getting exactly what he wanted - new functionality, but there was no question that it would need to be maintained and developed.
Unfortunately, this is a fairly common problem at outsourcing, when a company sells only the time of its developers, and customers cannot objectively evaluate the quality of the system, and the time it takes to solve its problems. When the cost of changing the code increases exponentially, it will only benefit the company itself to the outsourcer - more human hours can be monetized, and the company ordering the product will already be on the hook - it’s too late to rewrite the bulky and inconvenient system, since it requires huge investments and stopping the delivery of new functionality that cannot be allowed.
Code - the workplace of the programmer
For all the time that the article was in draft copies, I thought a lot whether this item should be included in it, but after a little observation of the priorities of candidates who are looking for work, I realized that this moment is really important.
Code is something that a programmer will have to work with every day, his creative product, what he creates, but creates not just one, but in a team, and often not from scratch. He needs to accept the already existing part of the project, develop it based on the functionality that was written before it. An employee will most likely be unpleasant to work in a product that is created poorly.
In the first place, in my opinion, is the team working together on the project. The quality of the resulting product directly depends on how the team work is built, on the internal rules and the requirements established inside it.
In second place is technology. A thoughtlessly chosen or inherited inconvenient framework, outdated and poor-quality tools, libraries nailed to the project place with all their crutches and bugs that you have to put up with, and the lack of people with sufficient competencies and time to eliminate legacy approaches can easily scare away new potential workers. In addition to the reasons stated above, this is also a smaller number of prospects and opportunities for the development of programmers, because instead of studying modern and most effective tools, it is necessary to develop props to adapt solutions to current problems due to historical reasons.
Why is this all
Unfortunately, the requirements for real applications can rarely be formed at 100%, and do not require revision during development. Moreover, the situation is almost impossible when the project does not have to be adjusted to new requirements after launch. The business expands, develops, requires functionality that was not discussed before, enters new markets.
It is almost impossible to build an architecture that is ideal and thought out to the smallest detail in such conditions, and, often, there is no need, because its cost in this case is unreasonably high for the initial stage of the project.
Certainly, writing good code should not be a headache for those who order software from programmers, and it is unlikely that anyone who can not write it can check it.
Nevertheless, a company developing a software product, if it wants to make it qualitatively, must understand that such a significant part of the product as its source code directly affects its success, and such things as refactoring the source code and modifying the architecture to the new requirements should also be a budget, time should be allocated to programmers. If someone is interested in the quality of the product, of course.
However, the IT industry is developing, products, companies, tools are developing, users are becoming more selective, competition is increasing, and there is hope that the future will still be with high-quality products.
Conclusion
In fact, the topic of the article is, of course, very controversial.
The above graph does not answer the question at what point in time the design of the system begins to pay off.
Technical debt for that and debt, which allows you to get a little more time now and give it back with interest later, and its main problem is extremely simple, and strongly resembles a similar phenomenon in the economy, is the inability to pay off debts and the inability to accurately estimate future income.
The quality of the code is also a very subjective thing, and, unfortunately, practically unformalized, otherwise the programmers could already be replaced by robots.
In any case, the most important thing is to achieve competent compromises and find that middle ground, which will allow us not to drown the project in the pit of technical debt in pursuit of functionality, and not to give up an interesting niche to competitors, doing system design instead of functionality.