A mature engineering organization possesses a software philosophy where saying no is commendable.
If there is a deadline or some sort of higher-up-pressure to deliver software within a tight scope, a mature engineering culture encourages to say no to such pressure if it compromises code quality.
If I were to go on LinkedIn and apply for a variety of jobs that came up when I searched "React developer," I would guess that most of the job descriptions would appear almost identical. However, each role could significantly vary based upon the engineering culture.
Truth be told, some engineering cultures are heaving "tactical." The main virtue is being able to deliver features as quickly as possible.
Developers that deliver very fast are enshrined by management as heroes, but the other developers think otherwise.
In a word, a tactically-minded engineering culture says yes to too much, takes shortcuts, and fails to think of long-term implications in a pursuit for short-term efficiency.
The code is becoming complex and needs refactoring, and a tactical approach says: "We can do a patch and get this delivered. We can always refactor later." Patch after patch the code spirals out of control, adding a level of complexity that slows down efficiency for the long-haul and produces a codebase that mature engineers (the one's you actually want on your team) don't want to contribute to.
This, in a nutshell, is a "tactical tornado."
What does this mean?
Engineers must think about the long-term consequences of their code on the developer experience.
There's a common camping maxim of "leave no trace."
Is it a big deal to leave a banana peel on the campsite? It's just a banana peel!
Well, yes--it is a big deal. The reason being that if one person sees that it's ok to leave a banana peel, then everyone thinks it's ok to leave behind a few scraps. Before you know it, everyone is leaving scraps and the campsite is a mess.
This maxim equally applies to software development
As with life, engineers should consider their legacy. Do they want to leave behind a messy, complex codebase for the gain of delivering faster for the short-term?
No. Developers should think beyond just writing code that works and instead writing code that follows good designs.
Good designs are not complex. They do not create unneeded dependencies and obscurity.
The code is easy to follow and easy to contribute to.
Good designs improve efficiency because they the code is easier to contribute to, and it prevents more mature engineers from jumping ship.
However, in the short term, good designs require deliberation--extra work, extra time.
This means that a quick patch is a big deal and should be said "no" to.
On the side of product management, mature yet efficient (thinking both in terms of short and long-term) developers should be encouraged and celebrated--not those who get work done the quickest.
Product people should understand the implications of bad software designs and how those do affect the bottom line in the long haul. To not understand this, and to not take an interest in code quality, is to manage poorly. If you ignore this aspect of management, then you'll have tornadoes on your hands.
Top comments (0)