Sustainable self-destruction is the golden mean lifestyle of most of us as individuals, the way we balance between too short term and too long term thinking and behavior.
We don’t like extremes. One of these extremes is total self destruction. If someone doesn’t care about the future and only considers having fun in the present or the short term, it certainly leads to serious negative consequences in the mid/long term. Consider hard drug addiction (that leads to dying young) or robbing a bank for having lots of money “easily” (that usually leads to spending a very long time in prison).
The other extreme is constantly pursuing ethical or religional perfection (and I’m not speaking about which religion is “right” and which one isn’t). If someone has total temperance and always behaves according to strict moral rules, it is definitely a short term competitive disadvantage, but in the long term it is perceived to lead to bigger harmony in life (and/or afterlife, whatever). Most people don’t like this philosophy either, as it is perceived to be less fun.
Most people usually try to balance this out, and have a lifestyle that I call sustainable self-destruction. Try to gain as much as possible (money, power, popularity, amusement etc.) as easily as possible, preferably not breaking the law in a very visible way and not hurting other people at least as much as our somewhat still existing conscience is still OK. Consider the health of ourselves and our planet. Sometimes even donate our time, energy or money to a noble purpose. For some people this balance can be quite a stable thing, some others keep going back and forth, but it’s basically the same thing: we aim for avoiding both too short and too long term thinking.
You may have guessed from the title: here comes the analogy with software development projects.
First extreme: too short term focus – We run towards burnout, technical debt, sacrificing our private life, code maintenance hell later on etc. for the fun of gaining quicker promotion or just getting bigger credit for delivering an enormous amount of features too much in a hurry, not caring about good architecture, code quality or having a great team.
Second extreme: Agile / Lean perfectionism – Always do pair programming, TDD, don’t release anything until all the 42 elements of the Definition of Done are fulfilled, this way most probably losing credibility with top management, failing to use windows of opportunities, not meeting customer expectations regarding deadlines (yes, deadlines), exceeding project budget and so on.
Traditionally, most good developers would prefer something closer to the second extreme, while project managers would vote for something closer to the first one. So in the end we arrive to some kind of a golden mean here as well. When we have to rush towards deadlines and accept ambitional project scopes based on aggressively (or even arrogantly) estimated backlog items, we do these to keep customers or product managers happy. However, when we don’t have to hurry too much, we “do our best” to increase automated test coverage, decrease technical debt, do more code reviews, improve the documentation etc.
This is again usually a constant struggle of back and forth. My theory (and wish) is that as we move towards continuous delivery, the amplitude of these back and forth waves decreases to an acceptable level.