“Is this a stupid idea?” the young software engineer asked.
His idea to build a more abstract testing framework was not stupid. It also wasn’t unique.
My experience is the desire to build highly abstract systems is very popular. As a Software Engineer specializing in Test Automation over the last 15 years, I’ve found it common. Avoiding mundane work (like writing test cases) is a keen focus for devs, especially for the smartest software engineers — and those earliest in their careers.
The problem in this case, is that I’ve seen exactly what he was suggesting – and I’ve tried it myself – at least a dozen times. I’ve seen it absorb at least 3 years of software engineering salary in the last decade alone. In fact, avoiding activities like this is exactly why companies pay me – to avoid wasting their money.
I had 2 options in responding to him:
1) Tell him it won’t work, likely demotivating him and encouraging him to ignore me from now on — he was going to run with this idea anyway OR
2) Find a way to make sure he had my experience in mind while attempting his idea
“Actually, I think it is a very smart idea,” I said — and I meant it. What I didn’t say is that sometimes the smartest ideas make the least business sense.
There are many, many smart people out there focused on abstracting test automation frameworks. Some have spent their entire careers on it. So what sense would it make to use the time and salary of an application developer to focus on creating yet another piece of software for testing?
Sure, he may create something that succeeds in its purpose — although I find it more likely that he’ll end up using the time to learn all the ways not to do it. Further, someone is going to have to maintain that software over time.
And during this effort of a smart idea, who will be writing the application code the company uses to pay his salary?
My experience is the best test cases are those that are concrete. If I can look at the name of a failing test case and know what part of the system is causing trouble, it saves me the time of having to debug my system, learn the test framework, and verify the environment is setup correctly.
I told him as much – my experience – the commodity his superiors were purchasing from me. I encouraged him to try it as a quick proof of concept and hoped it would force him toward experiencing the warning I raised.
I felt our relationship as teammates and his motivation were worth a day or two of creating a proof of concept. My experience tells me it’s not worth pursuing after that, but that’s not my call.
Smart ideas don’t always make business sense. They can be headed off quickly – but sometimes there’s as much of a hidden cost to mishandling a smart idea as there is to pursuing it when it doesn’t make business sense.
Thanks, Code Providence for the opportunity to guest blog. [Anytime, Paul! – editor]