When is a bug a good thing?

One of the glorious ironies of IT is that the CIO, the executive with “Information” in their job title, is frequently the least well equipped member of the management team when it comes to data. Information about project status comes from meetings with optimists (developers) and pessimists (testers). Really they should be called the Chief Opinion Officer instead.

The other glorious irony of IT is that we manually run the automated test suite! Now I have a vision of how development should be: fair warning this is an idealistic and romantic dream of a far-away development future.

Wouldn’t it be interesting if the first thing a developer did was to look at the work assigned to her, her “tickets”, right there from within her IDE. No popping out to the ticketing systems to get the daily task list.

And what if every piece of code she then touched, every change she made, was automatically “stamped” with the ticket number to give a complete audit trail for root cause analysis later.

When it came time to check code in the build tool would kick off immediately and, if it failed, would open a new, high-priority, ticket in the developer’s inbox in her IDE. Maybe even with a social media beep to get her attention.

Of course if the build is successful the automated test suite would run, AUTOMATICALLY, exercising those pieces of code that had changed or were impacted. That would mean a correlation between test scripts and code changes and an impact analysis tool that could understand upstream and downstream dependencies.

Should any of the battery of tests, functional, performance, non-functional, fail then a new ticket would be opened in the developer’s inbox.

Notice that what this means that the developer never gets to hand over code that does not build or does not pass the battery of automated tests. So what happens to the Quality Assurance team? Well, they start to assure the quality by catching everything else that gets missed.

A programmer once told me “I just spent all morning debugging the code and now I am spending the afternoon rebugging it.” The idea that we can rely on someone else to find our bugs is out dated and a very poor use of our best talent. After all “testers” didn’t put the bugs in, can’t take them out and are nobody’s clean-up crew.

We have to learn to say “no” in IT. If the requirement doesn’t make sense – send it back. If the code is incomplete and buggy – send it back. If the test plan isn’t comprehensive and is not automated – don’t test until it is. Far too often we pass our problems on downstream and when the same is done to us we grin and we bear it.

My first boss said to me when I was a newly minted programmer, “if you don’t have time to do it right when do you have time to do it over?” We should make every effort to test every aspect of the code we can before we are allowed to check it in. We have the technology available today to do that. But do we have the will?