You have to choose which software you need: written on time or in quality

I hope that I was able to draw your attention to such a provocative (and, to admit, exaggerated) title. Good. Now let him reformulate it in a slightly more elegant and less enticing way:



In principle, the software can be written either on time or well, but not both at the same time *

')

* with the exception of a few cases in the existing high-performance teams



For several months now, I have been pondering why the creation of high-quality software does not fit well with the estimated time frame and planning in general. During my career, I saw projects built on a variety of models (cascading, truly flexible, flexibly cascading), and all of them had one thing in common: no matter what project we are working on, if it was done “ according to science” ( ie, we did not allow ourselves dirty tricks, because of which we would then have nightmares), then we always broke deadlines.



On the other hand, whenever the project surrendered “on time”, this meant that along the way, it inevitably had to reduce its volume, or cut off so many corners that during the implementation mountains of technical debt accumulated, almost guaranteeing that the project would have to be rewritten shortly after launch. Therefore, I began to wonder: can it really be considered that the project was delivered “on time” if, as a result, we have an ugly, inconvenient in support, stuffed with bugs and, frankly, a more unattractive version of the code compared to what we originally tried to do?



Transferred to Alconost



I have worked on projects without tight deadlines. Yes, formally, the "deadlines" were there, but far from reinforced concrete. Everyone understood that the deadlines were flexible and that quality was more important than timely delivery of the product. It was on these projects that we got the best software, there were the most satisfied developers, and, in general, these projects were among the most successful among all that I had to work on. But we all know that such projects are rare, otherwise I would not have written all this.



So, why is it so difficult to plan a job and give out good software, having tightly defined deadlines? I think this is largely due to creativity , skill and unpredictability .

Creative side of programming

I am of the opinion that software development is, by definition, a creative activity . Of course, there are developers who perform monotonous trivial tasks, but they only have work until someone can figure out how to automate their work. They do not envy, and the topic of this article is completely different.



For me, there is something special about the act of creating something new and finding original solutions in response to challenges; that's why I feel the vocation to develop software, and I don’t think that I am the only one. In fact, I believe that creativity is the main reason why developers enjoy their work. My experience suggests that whenever I have worked in an environment where a strict and consistent “set of practices” has been observed (be it a technological stack, processes, regulation, etc.) - that is, the less space for creativity I was - the less I was fascinated by such work. “In the end, if they had already decided everything for themselves, then why should I?”, I thought. On the other hand, I was much more filled, inspired by such work (in which I was and most productive), where there were relatively few directives from above, there was room for creativity, and they trusted me to make technical decisions myself.



It is important to note that additional creative freedom leads to the fact that on the way to reaching a solution there will inevitably be more trial and error - and this is normal. Some people think that one can simply know the ideal solution a priori (in advance), without having written a single line of code yet. I, on the contrary, insist that in the creative process, the path to the discovery of the solution of the problem (this applies not only to software) requires tinkering : it is impossible to know everything for sure in advance; on the contrary, you learn through practice, gradually sorting out all the new options and adhering to those that work, honing your decision (and, perhaps, gradually handing it over to customers, if you work according to the “flexible” methodology) until you are happy with it.







Just think how many times it has been painstakingly to design a component on paper - only then, in order to completely redo the design, you just had to start the implementation. In this case, there will always be unknown unknowns, and you can only identify them and deal with them a posteriori (in fact), programming your solution, and not spending a lot of time on theorizing and not pretending that we can have the perfect information in advance. Such improvisation does not fit well with the estimated time frame.



In addition, as in the case of other creative activities, it is useful to practice strategic procrastination when programming - this term was first suggested by Adam Grant, who asserted that creativity is often not possible on demand, but, on the contrary, creativity comes as a “push-notification ” from The process running in the background is in your head:

“Regularly procrastinating employees usually devote more time to divergent thinking, and curators more often rate them as more creative than their colleagues. Procrastination does not always fuel creativity: if an employee does not have a confident motivation to solve a major problem, then he simply lags behind due to slippage. However, if a person is passionate enough to do business and gives out new ideas, then postponing the task, he comes to more creative solutions . ”

- Grant, Adam. “Originals: How Non-Conformists Move the World”

Again, this will not please supporters of central planning , seeking to provide and measure every minute in software development projects.





Milky Way , Mars and Meteor

Mastering the creation of programs

The best developers I know are skilled craftsmen. Skill is a characteristic feature of good software: you create something that works, and you create it in the best possible way — it is relatively easy to create something working, but it is very difficult — not only will it work, but it will stand the test of time.



Since you are a master, the quality of your work speaks of you . For you, quality is more important than quantity, because you don’t want to be the author of a govnokod, even if you could satisfy a product manager by giving your program a glossy look, and inside nipping it with a bunch of vile surprises — I call this approach Kindersurprise Development . You know that giving the case enough time and writing a good program is right, so resist the “do it faster” pressure, because you know that the more crutches you have now, the more short-term your code will turn out and the more problems you will have with it affairs





Eyes bleed



Skill is connected with care : we take care to do an excellent job, those who will have to maintain our code after us, our customers who should be easy to handle our program, teammates, etc. You do this because you are not an asshole and because you know that this is what you should do if you care for the success of the project.



In short, a good engineer gets a difficult task: to take care of quality - which will be felt in the long term - in a world where everything is done in a hurry.



In practice, this is expressed in such things:

• Find the right combination between encapsulation, extensibility, scalability, etc. - again, an iterative approach will be required by trial and error, because no one can pile the best solution on the first attempt.
  
  
• Take some time to refactor if you stumble upon a shamefully bad code snippet.
  
  
• Write good, complete tests - maybe even do TDD
  
  
• Program in tandem with a colleague
  
  

Needless to say that it is impossible to plan all this in advance, therefore such an approach would still not help you meet the deadlines.

Your predictions are wrong.

“Even in the presence of clear requirements - and such, apparently, never happens - it is still almost impossible to calculate how long it will take a specific job, since we have never solved this task before. If you decide - then just give you the result. "

- Ron Jeffries, Movement NoEstimates

Software projects are Complex Systems : they are created by people, and therefore bear the imprint of interpersonal relationships, motivation, communication problems and human psychology in general - all this is very difficult to model and quantify in the table if you are interested in my opinion. So, software projects are very difficult to model (and, therefore, predict). This is best explained by Nassim Taleb in his book Anti-Fragility :

“Complex systems are distinguished by their large interdependence (which is difficult to recognize) and non-linear reactions. “Nonlinear” means that when you double, for example, the dose of medicine or the number of employees in the plant, the return will not be twice as much, but either much more or much less. I can’t say that two weekends in Philadelphia are two times more pleasant than one - I can say this from my own experience ... ”.

- Nassim Nicholas Taleb, "Anti-frailness"

Worse, given that time cannot be a negative value, any unplanned “surprises” will most likely postpone the completion of the project, rather than bring it closer, since there is an asymmetry of results:

“Time is not a negative value, which means that a three-month project cannot be implemented in a zero or negative time period. Therefore, on the time axis, which moves from left to right, errors accumulate on the right, not on the left. If the uncertainty was linear, we would see that some projects are completed significantly ahead of time (as we sometimes arrive at the site much earlier, and sometimes much later). But the reality is not so. "

- Nassim Nicholas Taleb, "Anti-frailness"

This is bad news, as uncertainty is guaranteed , and even small errors in the assessment of individual tasks will accumulate exponentially on a project scale. Moreover, here we consider the best case when deadlines are set by the developers themselves after a careful assessment of the deadlines. However, the reality is much more absurd: in most cases, “business” sets deadlines as it pleases, and only then engineers who plan to meet all requirements for this arbitrarily specified period take up the task; a case as glaring as starting a house from a roof, not from a foundation, or putting a cart before a horse.





Good question



Here are some examples that demonstrate the non-linearity of software development and the resulting feedback cycles:

• Once you assumed that the API you want to contact accepts accountId , but in fact it accepts only memberId . We add to the approximate time limit of 4 days, which are necessary for refactoring the API code - after which, in turn, we will need a separate review, to which we will add another 2 days.
  
  
• The task we expected to solve in 2 days stretches for a week, because in the course of the review one of the colleagues forces you (and rightly so) to refactor and optimize the disgusting code snippet, which has long been waiting for its time.
  
  
• Recall that one-time task when you only needed to implement one new feature. But it turned out that for this you need to update the dependency, which took 4 days, and this operation provoked a chain reaction with updating other dependencies and a whole bunch of dependencies during assembly.
  
  

Did we screw up?

By inertia we simply continue to play this game with estimates and planning, just to assure ourselves: we are supposedly in control of the situation. But in reality we control nothing; Experience shows that software projects are unpredictable. Therefore, I think it is better to focus on business rather than planning - #NoEstimates , who is with me? However, of course, in many organizations this is not a ride: “You cannot just take and let the engineers fill up with a ball so that no one controls them. There must be accountability! ” I understood.





You do not say that?



What then to do? I think it comes down to reducing the gap between the world of tables and the world of IDE in such a way as to provide engineers with maximum creativity, flexibility and freedom to show skill, however, at the same time, responsibly adhere to the promised and meet the expectations of the project stakeholders. Technical Manager (Engineering Manager) - the best specialist in building such bridges, which can also absorb the gap between the two worlds. This work is not easy, but necessary. Here is how well Aaron Longwell speaks about her in her article:

“Since technical managers live on the border between business and techies, they have to settle the contradictions between expectations and reality. They are like a lever suspension, which is pulled in different directions: it can snap on both sides. If business wins, developers are driven to death. If the engineering arguments outweigh the business, then farewell to the budget and deadlines. In any case - failure. A successful software project manager finds ways to act flexibly; give way, without breaking, and gradually resolve friction. A “leadership as a ministry” approach can help you find that flexibility. ”

- Aaron Longwell, Why Software Development Requires Servant Leaders

It is also very important to establish strong trusting relationships between Production and Engineers. If there is trust, then you can honestly and conscientiously negotiate timelines. If you have previously proved that your team is doing good software, then you should have a fairly good reputation, and the stakeholders should trust you, knowing that if you are out of schedule, then for good reasons and for the common good.



Another “trick” that I personally used as a manager was not to mention specific dates, since they inevitably turn into tight deadlines. It is better to give fuzzy terms, for example, "three to five weeks." In this case, when approaching such a shaky deadline, you add: “in April or May”, which is easily interpreted as “Between April 15 and May 3” in early April, around April 10 may turn into “By 20 to April ”, etc. In this case, you are not cunning, communicating with colleagues, and the team provides the flexibility of time that will be needed to resolve the inevitable unforeseen problems that arise.



Finally, remember that it is the developer who should be responsible for the technical quality of the product being issued, and not other interested parties. Naturally, there will be friction between organizations that, at first glance, are guided by different incentives. In this case, the most important thing to note is that all of you (presumably) are united by a common goal: to provide the customer with high-quality software as soon as possible. Apparently, only good developers are able to think in this way and understand that it is important to avoid the deceptive approach “Once, twice, and you're done!”, Which in the long run turns out to be the slowest.



In conclusion, I will say that this is a solvable, albeit a complicated (and common) problem. I would say that if, in your opinion, your manager or your organization is not in the mood to write good software, you need to comment on this and try to change it; if this fails, find another job.



About the translator



The article is translated in Alconost.



Alconost is engaged in the localization of games , applications and websites in 70 languages. Language translators, linguistic testing, cloud platform with API, continuous localization, 24/7 project managers, any formats of string resources.



We also make advertising and training videos - for websites selling, image, advertising, training, teasers, expliners, trailers for Google Play and the App Store.



Read more