Hard Programmer Manifesto
Foreword
This text assumes that the reader is familiar with the so-called. agile manifest software development and its so-called. underlying principles .
At the moment there are a huge number of people who accept this "manifesto", agree with it, and even try to use it. But for me personally, it looks like a joke that has dragged on.
Content
Hard Programmer Manifesto
We are constantly discovering more advanced software development methods, developing ourselves directly and helping others. Thanks to the work done, we were able to realize that:
The concept is more important than new requirements.
Quality is more important than speed.
Doing what you need is more important than doing as requested.
That is, without denying the importance of what is right, we still more value what is left.
The fundamental principles of the manifesto of a hard programmer
The highest priority for us is the fruitful and productive work of the programmer, thanks to a well-thought-out plan and following the software development technology. And, as a result of all this, satisfaction with the results of their work.
Changing requirements is possible, but new requirements must go through the same stages of understanding that all old requirements have gone through. The customer must be aware that changing the requirements may entail processing the product.
The product should be released only when it reaches the required level of quality. No, there can be no fixed periodicity.
Everyone must understand what he does and try to do it well. Unsuccessfully done work on sales or planning should not turn into an endless stream of amendments to the requirements or deadlines, that is, passed on to engineers.
The project should work motivated professionals. To get the job done, create the conditions, provide support and trust them completely.
Direct communication should not interfere with immediate work. Meet when they are needed by the work process.
Quality product - the main indicator of success.
No one should work "for wear". You need to work calmly, without following unreasonable "rhythms" and "cycles". Recycling is not allowed.
Constant attention to the process improves the quality, reliability and flexibility of the system.
The best requirements, architectural and technical solutions are born from teams that work closely on requirements, architectural and technical solutions.
It is useful to conduct reports and seminars in order to increase the general professional level and degree of involvement in the overall process.
Comments on the manifest
Concept is more important than new requirements
Before you start developing software, you need to do two things:
- Develop software model;
- Think over software architecture.
If the customer suddenly resorts with new requirements, then you need to be not “ready for changes”, but ready to compare the new requirements with the old concept.
If the requirements fall on the existing model and architecture - fine. Put the task in the queue. If they do not fall, then you need to either adjust or discard the new requirements, or change the model and architecture so that the requirements for them are laid down. And this is a new planning, a possible rework of what has already been done, that is, time and money.
If the customer does not understand this, then he needs to patiently explain it, and not rush to the first call to run in the direction indicated by the fleeting wave of his royal hand. Otherwise, instead of the software comes a bunch of stinking garbage.
Quality is more important than speed
In other words, the technical process is more important than the timing.
At construction go helmets. Why? Because it requires safety.
Software developers write tests and documentation. Why? Because such is the software production technology.
Numerous offices dump tons of idle or poorly working, ahem, software, instead of spending a little time to bring it all to mind. And then they start to fix bugs.
With alarming regularity, there are signals that the next application (or even the whole OS) after the next update stops working. What about weekly "technical" updates that improve "overall stability and reliability"? Familiar?
We ourselves create this vicious circle: everyone is in a hurry, so we are in a hurry, so everyone is in a hurry. It's time to stop and think.
Doing the right things is more important than doing what they are asked
Sits programmer Ytsuken. The manager Yachsmith comes to him and says what needs to be done Xby next Monday. But Ytsuken knows that in order to do this X, you need to go through literature and articles, think over the model and architecture, write code, tests, documentation, and less than three weeks it all just will not work, because A, Band probably C.
But Yachsmit is an “energetic” person with an “active lifestyle”, so he explains to Ytsuken that “the market is changing dynamically,” and an urgent need is to “run down” in order to “occupy the field”. Ytsuken gives in, breaks deadlines and gets a hat - from Yaxmith, of course.
But Ytsuken wants to do what he likes, and do it well. Therefore, Ytsuken, assessing the present period, should not rush to have time , but explain to Yachsmith that it is impossible to break the technical process, that by next Monday it will not work, and that X, according to the technical process, it will take at least Yweeks, because some work must be done. After all, Yachsmit will not push the surgeon who operates his heart, because Yachsmit is late for a meeting with the client of his employer? Or will it be?
→ Top
PS
Brief summary of the discussion.
Two of the three main opponents of this manifesto would be blackmailed by dismissing an engineer who says that the work is not being done on the deadline "from above".
... if you came to our company in order to receive a two-month salary for useless activity on writing code that will never be launched - please write a statement on your own right now ...
powerman
The next action is dismissal on the initiative of the employer and you can go to court with this. :)
DexterHD