Forgive me, father, for I have sinned.








I have sinned. In the pursuit of silly and stupid goals and beliefs, I have committed crimes against quality, delivery dates, and the businesses I have worked in.

Goals like:

  • We need to move quality upstream
  • We need to automate everything
  • We need to automate in order to scale
  • Friction-free automation is the key to unlocking limitless potential

What did I do?

I (along with my accomplices) created a hugely powerful, popular, and flexible automation system. It’s even patented (though, not available publicly).

I created this system with 3 primary goals in mind:

  • Freedom – I wanted an automation system that let feature teams decide how to automate without becoming a burden to execution staff. Often times, I encountered folks trying to “standardize” automation efforts in order to “avoid duplication”. But these standardization efforts often entailed teams having to rewrite their functioning automation suite just to toe the line. Often at greater long term cost than maintaining the already stabilized, but no longer in favor, automation suite. In addition, these automation efforts often were a least common denominator approach, where the system solved 80% of the problem for everyone, but was not able to solve the P1 issue for a feature team, making it a non-starter or an excessive burden.
  • Friction-Free – I wanted a system that a “brainless monkey could use while sleeping”… I argued by making it so easy to utilize, we could hire much cheaper staff to get work done, saving money.
  • Cheaper – by doing the above, the system will enable teams to create more automation thereby making test passes cheaper.

If only I could go back 15 yrs and slap myself in the back of the head…. Hard…

Um, Brent, those goals seem awesome. What gives?

First off, I succeed in all 3 goals. But here’s what happened over time:

  • By enabling team freedom, I enabled the execution team to scale and handle more and more automation frameworks, test cases, etc
  • By doing this, teams got more invested into their automation infrastructure and created more and more collateral faster and faster
  • As more and collateral got added, the system remained “friction-free”, so there was no reason to think deeper on improvements. The reduction in payroll cost justified the increase in machine execution cost (though, neither were measured).
  • So more and more test passes got scheduled, this in turn, increased automation maintenance cost, total payroll, total machine cost, etc…










In short, I helped to create Test Zombies, but not only that I created Dev Zombies too. By trying to move quality upstream, I did the exact opposite.


I  had enabled brainlessness to thrive.

How to fix?

Learned from my Agile training, Systems Thinking helps to see the way. Lean Agile has an important principle that specifies we need to “Optimize the Whole”. This means that one should consider the final goal and determine the right things to do in the immediate context to achieve that final goal. In my case, by making test passes cheaper and encouraging simplicity., I essentially helped the team optimize for *more* test passes using cheaper resources. Ultimately, costing the business more money via the need for more and more machine resources, and while we could hire cheaper people, the test pass load was such that we needed more and more of them to maintain the machines, schedules, etc and lastly, we had enabling the dev team to produce arguably sub-standard code and still succeed. And what’s worse: almost all of the participants, when they think of their own sub-goals, will today *praise* me for what I have done….

By changing the “Cheaper” principle to be around decreasing the pricetag for regression testing for each milestone and/or release and increasing the efficiency of the program, the implementation strategy and therefore, the automation strategy changes in very important ways.

But that, my friends, is a story for another day.