I want to be beautiful!
Each programmer with the accumulation of experience has a certain heightened sense of beauty. I think this feeling is familiar to many. Over time, a “taste” is formed for the contents of the program or its architecture. There is an understanding that this should be done this way, and not otherwise, what is good and what is bad. There are even professional whims ( I hate it when the bracket is moved to the next line! )
By the way, what phrases do we use at work?
In general, as aptly noted , programmers are like children. That is, their decisions are often based on emotions and taste preferences. Some generally believe that it should be so that the professional appointment of a programmer is pure, uncomplicated creativity, the birth of beauty, the soaring, so to speak, of intellect over base instincts. Such people are very often surrounded by renegades, degenerates, bureaucrats that interfere with the creative process.
Something must probably happen in my head for the programmer to grow out of this infantile state and develop a certain understanding of the problem for him. I want to point out a few key points that I call “pragmatic.” This is how many project managers around the world work. In parentheses, I note that we are talking about a) - about projects from medium to large sizes b) - about teamwork (projects that are written by individuals are not very indicative in this regard).
So, you are a project manager, technical manager, architect or team lead. A programmer comes to you, tortured by fixing bugs, and offers a new super-technology, or “rewrite everything”, or a new programming language (friends said that in PHP you can write all this three times faster!). How to make a decision?
There are no ideal (from the architect’s point of view) software systems that work and develop. I would even say tougher: bringing the system to a completely perfect look, as a rule, is fatal for the system. Or the owners of the system have a lot of money and programmers are bored - indeed, such phenomena occurred before the crisis.
If one of my colleagues begins to violently express a desire to improve something, to “make it beautiful”, to start life from scratch, I first suggest that this person write tests for existing functionality. Very often after that, all emotions quickly go out. By the way, I propose that this be done not out of spite, but on the basis of the methodology for assessing the complexity of refactoring described here .
There is nothing wrong with wanting to rewrite everything. Indeed, junk code disfigured by numerous hotfixes and backups is often found in life. Indeed, refactoring is part of the life cycle of modern software. However, there is no need to scamper about this issue. Seriously cool the programmer’s hot head are, for example, the following questions:
As you can see, everything is pretty rational. In fact, we are guided by some kind of business arithmetic, where all numbers are weighted in terms of real benefits. You can even come up with a “solution calculator” that will bring all pros and cons digitally :)
I knew the CIO who, in his spare time, wrote small network services in Java. Just like that, for fun.
So what, the farther, the less space for creativity? Not certainly in that way. If the project / system is developing, then new, fresh ideas and modern “top-notch” technologies will be needed. However, without the desire to accompany and endlessly pick the existing code, nobody needs these ideas.
By the way, what phrases do we use at work?
- Very bad code, you have to kill the developer and rewrite everything.
- It's easier to redo everything than fix this bug!
- Conservatives! It is necessary to use mega-library version 2.0, and not the long-obsolete version 1.6.2.52.
In general, as aptly noted , programmers are like children. That is, their decisions are often based on emotions and taste preferences. Some generally believe that it should be so that the professional appointment of a programmer is pure, uncomplicated creativity, the birth of beauty, the soaring, so to speak, of intellect over base instincts. Such people are very often surrounded by renegades, degenerates, bureaucrats that interfere with the creative process.
Something must probably happen in my head for the programmer to grow out of this infantile state and develop a certain understanding of the problem for him. I want to point out a few key points that I call “pragmatic.” This is how many project managers around the world work. In parentheses, I note that we are talking about a) - about projects from medium to large sizes b) - about teamwork (projects that are written by individuals are not very indicative in this regard).
So, you are a project manager, technical manager, architect or team lead. A programmer comes to you, tortured by fixing bugs, and offers a new super-technology, or “rewrite everything”, or a new programming language (friends said that in PHP you can write all this three times faster!). How to make a decision?
The ideal is unattainable
There are no ideal (from the architect’s point of view) software systems that work and develop. I would even say tougher: bringing the system to a completely perfect look, as a rule, is fatal for the system. Or the owners of the system have a lot of money and programmers are bored - indeed, such phenomena occurred before the crisis.
If one of my colleagues begins to violently express a desire to improve something, to “make it beautiful”, to start life from scratch, I first suggest that this person write tests for existing functionality. Very often after that, all emotions quickly go out. By the way, I propose that this be done not out of spite, but on the basis of the methodology for assessing the complexity of refactoring described here .
We need to rewrite
There is nothing wrong with wanting to rewrite everything. Indeed, junk code disfigured by numerous hotfixes and backups is often found in life. Indeed, refactoring is part of the life cycle of modern software. However, there is no need to scamper about this issue. Seriously cool the programmer’s hot head are, for example, the following questions:
- How long will it take to rework? At the same time, in my mind, I take into account that fans of rewriting are always inclined to underestimate the complexity. By the way, rewriting the code will be done not only by its initiator, but also by the whole team.
- What are the risks? Risk management is generally a vast and interesting topic (perhaps I will write about it separately). To simplify, imagine that any risk can be expressed as a percentage, which will increase the complexity of the work, if this risk still arises. Let's say Vasya or Petya comes to you and excitedly says that the performance of his server application can be seriously improved by adding just one line of code. One bad luck - this line is added to the Linux kernel code . The cost of such an operation is minimal, but the risks are off the charts. Now try to explain it to Vasya or Petya, who consider you a reinsurer.
- How many new features are expected in the future? There are sections of the project in which the number of potential changes is minimal. If they are independent of everything else, why not leave them to live their own, certainly unhealthy, but still life?
- What business priority does this task have? The manager, as a rule, constantly keeps these priorities in mind. From the developer's point of view, dealing with some kind of production problem is boring and boring, and writing new code is fun. However, the hour spent fixing the bug can bring the business $ 10K, and writing new code or a new cool upgrade in the end can bring nothing but the moral satisfaction of the programmer.
As you can see, everything is pretty rational. In fact, we are guided by some kind of business arithmetic, where all numbers are weighted in terms of real benefits. You can even come up with a “solution calculator” that will bring all pros and cons digitally :)
I'll go to the artists!
I knew the CIO who, in his spare time, wrote small network services in Java. Just like that, for fun.
So what, the farther, the less space for creativity? Not certainly in that way. If the project / system is developing, then new, fresh ideas and modern “top-notch” technologies will be needed. However, without the desire to accompany and endlessly pick the existing code, nobody needs these ideas.