TL;DR Poor (in terms of engineering culture standards) work environment doesn't just impact negatively the end products (quality, fit-for-purpose), development process (effectiveness, efficiency) & people morale - it can also deteriorate their skills, attititudes, long-term motivations. One with high standards is not likely to welcome happily the sudden, significant drop, but we fool ourselves by justifying short-term "compromises" that slowly (but cumulatively) lower our baselines, effectively turning us into much more inferior engineers over longer period of time.

If you were to describe an archetypical engineer with just one adjective (that depicts the most desired/characteristic trait of such an archetype) - which one would you use? I would go for "pragmatic". And what is pragmatism about? Making hard choices between what's optimal (/best) and what's feasible (/affordable) - prioritizing where to put efforts now (& then), or like some use to say: "picking your own battles".

There's nothing wrong in this definition, I still think that pragmatism defined this way is one of the major factors that defines one's maturity as an engineer, but I've also noticed too many cases where "pragmatism" is being used as an excuse, a smokescreen that hides something completely different behind:

  • aversion to change
  • "this is how we do it here" syndrome
  • low A2E (Ability-To-Execute)
  • and in the end - (semi-consciously acknowledged) mediocrity

And no, it's not a rambling about "the perfect design" or "the cleanest architecture" - I refer to obvious deficiencies / bad practices that clearly offend rules and principles of engineering.

Continuous Motion

All management theories teach us that "change" (in behaviors, people, whole organizations) is very hard (yes, it is), it can be overwhelming (indeed), so it has to be dosed with a suitable pace, adjusted to the environment (hmm, yes and NO). The thing I'd like to emphasize is that software development team (/unit) is not ANY (or typical) environment - embracing gradual, frequent changes is (should be) the absolute baseline here.

Engineeers' (as a group) appetite for change (& capacity of change that can be accommodated within a period of time) should be significantly higher than the average in the society.

Disclaimer: certainly the change itself should meet given qualities: conclusive, feedback-enabled, focused, aimed for goal (e.g. solving particular problem) - chaotic Brownian motion is definitely not something I would recommend.

Entropy by indifference

So why do I refer to the change in context of software engineering environment? Because I'd like to encourage you to stay firm & never lower you standards. I've read somewhere recently (Dalio? I'm not sure really) a great statement about the risk management - I don't remember the exact wording, but the concept can be summarized as follows:

If you accept a recognized risk w/o any actions / follow-ups, it becomes the new "normal" (state) in a very short time. So, over the longer period of time what you perceive as "normal" in fact becomes a house of cards (risk has accumulated), prone to multiple risks you've already neglected.

This theory, when mapped to engineering (quality) standards is sometimes known as a "boiling frog effect":

  • if you get the frog out of a pot filled with water at normal temperature & throw it into the one filled with boiling water, it will immediately jump out in panic
  • but if you (instead) slowly heat the pot (starting at normal temperature), frog will not notice any change & remain in the pot until it's too late (it dies in the boiling water)

Accepting the "slight", "temporal" (LOL) lowering of your engineering standards (because of e.g. "pragmatism" ;P) degrades your new "normal" - I've seen reasonable people unquestioningly shrugging in response to idiocy they would never consider seriously few months before. Whole this industry is all about practice & practical experience, so embracing mediocrity overal substantial period of time in fact makes you WORSE ENGINEER that you were before!

Cool down, not heat

OK, fine, so what are the countermeasures? Should we ignore all other priorities & fix broken stuff first, effectively postponing implementation of new business requirements until next November? Certainly it would be neither pragmatic nor realistic. Why not to try something like that:

  1. Don't just ignore issues, backlog them up (& keep grooming / cleaning it as well)
  2. Unless in prolonged firefight, keep at least 1 improvement experiment (aimed to fix stuff) running
  3. Stuff on the top of the list (highest priorities) should have their owners (accountable people - SPoCs)
  4. Principle "always leave the stuff you touch in not worse shape than it was before" is absolutely crucial & fundamental. Some would refer to so-called Starfish Principle - fix tiny things on the daily basis, the summarized effect over long period of time will make a huge difference
  5. Never stop preaching & evangelizing desired values (/qualities), but what's even the most important - do apply them yourself hence leading by example! aka don't expect others to conform to something you don't conform to

Let's say that straight & openly - there are organization where this will not work at all. And there are some where your expectations (standards' level) will not match organizations' ones - which simply means you prolly should "play in different leagues". It's really simple: if you're forced to jump from compromise to compromise on the daily basis & there's no indication of gradual (but regular) improvement, it means that you either adhere to mediocrity (& in fact - prolly do yourself some "professional harm") or evacuate.

Like a leaping frog, who has just decided that this pot is getting far too warm ...

Share this post