Want to beautiful!
Each programmer with the accumulation of experience has a kind of keen 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 when the bracket is transferred 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, soaring, so to speak, of intelligence over lowly instincts. Such people are very often surrounded by renegades, degenerates, bureaucrats who interfere with the creative process.
')
Probably something should happen in the head, so that the programmer grew out of this infantile state and a certain understanding of the problem developed in his person. I want to point out a few highlights 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 medium to large projects; b) - about working in a team (projects that are written by singles are not very significant 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 all this can be written in PHP three times faster!). How to make a decision?
Ideal (from the point of view of the architect) software systems that work and develop do not exist. I would even say tougher: bringing the system to a completely perfect look, as a rule, is deadly for the system. Either the owners of the system have a lot of money and programmers are bored - indeed, before the crisis, such phenomena occurred.
If one of my colleagues begins to violently express a desire to improve something, “do it beautifully”, to start a new life, I first suggest that this person write tests for the existing functionality. Very often after that, all emotions quickly go out. By the way, I propose to do this not out of malice, 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, in life often there is a garbage code, mutilated by numerous hotfixes and props. Indeed, refactoring is part of the life cycle of modern software. However, the fuss in this matter is not necessary. Seriously cool the hot head of a programmer may be such, say, questions:
As you can see, everything is quite rational. In fact, we are guided by some kind of business arithmetic, where all numbers are weighed in terms of actual benefits. You can even come up with a “solution calculator” that will bring all pros and cons into digital form :)
I knew a CIO who, in his spare time, wrote small network services in Java. Just for fun.
So, the farther away, the less space for creativity? Not certainly in that way. If the project / system develops, then new, fresh ideas, and modern "top-notch" technologies will be needed. However, without the desire to accompany and infinitely pick the existing code, no one needs these ideas.
By the way, what phrases do we use at work?
- Very bad code, you need to kill the developer and rewrite everything.
- Easier to redo everything than fix this bug!
- Conservatives! You must use the mega-library version 2.0, and not the outdated version 1.6.2.52 long ago.
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, soaring, so to speak, of intelligence over lowly instincts. Such people are very often surrounded by renegades, degenerates, bureaucrats who interfere with the creative process.
')
Probably something should happen in the head, so that the programmer grew out of this infantile state and a certain understanding of the problem developed in his person. I want to point out a few highlights 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 medium to large projects; b) - about working in a team (projects that are written by singles are not very significant 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 all this can be written in PHP three times faster!). How to make a decision?
The ideal is unattainable
Ideal (from the point of view of the architect) software systems that work and develop do not exist. I would even say tougher: bringing the system to a completely perfect look, as a rule, is deadly for the system. Either the owners of the system have a lot of money and programmers are bored - indeed, before the crisis, such phenomena occurred.
If one of my colleagues begins to violently express a desire to improve something, “do it beautifully”, to start a new life, I first suggest that this person write tests for the existing functionality. Very often after that, all emotions quickly go out. By the way, I propose to do this not out of malice, but on the basis of the methodology for assessing the complexity of refactoring described here .
We must rewrite everything
There is nothing wrong with wanting to rewrite everything. Indeed, in life often there is a garbage code, mutilated by numerous hotfixes and props. Indeed, refactoring is part of the life cycle of modern software. However, the fuss in this matter is not necessary. Seriously cool the hot head of a programmer may be such, say, questions:
- How much will the alteration take? 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, not only its initiator, but also the whole team will be engaged in rewriting the code.
- What are the risks? Risk management is generally an extensive and interesting topic (perhaps I will write about it separately). Let us simply imagine that any risk can be expressed as a percentage by which the complexity of the work will increase, if this risk does arise. Suppose Vasya or Petya comes to you and says avidly 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 just going wild. Now try to explain this to Vasya or Pete, who consider you a reinsurer.
- What number of new features (features) are expected in the future? There are project areas where 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 point of view of the developer, it’s hard to deal with some kind of production-problem, and writing new code is fun. However, the hour spent on fixing a bug may bring a business $ 10K, and writing a new code or a new cool upgrade may not bring anything but the moral satisfaction of the programmer.
As you can see, everything is quite rational. In fact, we are guided by some kind of business arithmetic, where all numbers are weighed in terms of actual benefits. You can even come up with a “solution calculator” that will bring all pros and cons into digital form :)
I will go to the artists!
I knew a CIO who, in his spare time, wrote small network services in Java. Just for fun.
So, the farther away, the less space for creativity? Not certainly in that way. If the project / system develops, then new, fresh ideas, and modern "top-notch" technologies will be needed. However, without the desire to accompany and infinitely pick the existing code, no one needs these ideas.
Source: https://habr.com/ru/post/68366/
All Articles