Uncharted Waters

May 22 2018   5:43PM GMT

Working Outside of the Process

Justin Rohrman Justin Rohrman Profile: Justin Rohrman


A few years ago I was on an overworked team. Big surprise there, right? We were working on a long list of work for an upcoming release. We through everything was documented in our bug tracker, but you know software, the more you dig into the work the more new scope you discover. We would work on a change, and discover that there were hidden requirements, or that the code base was a rats nest that had to be addressed before we could actually get work done.

Our development team usually took care of this by either documenting the new scope in a card and getting it queued up for future sprints, or they would get the changes done at night or on the weekend without it ever hitting our bug tracking system.

Sometimes this was good, sometimes it wasn’t.

The “ideal” (the quotes are for sarcasm folks) scenario of course is that a heroic developer swoops, fixes all that scary legacy code over night or on their precious weekend, and then on Monday we are ready to go. Let’s ignore that flip mention of hero culture for now, I’ll write about that another day.

software process

Here is what really happened on that project. We were working in a large monolith Java code base and a developer made a few changes over the weekend. He mentioned those changes to the rest of his team on Monday and then they continued on. There was no code review and no normal testing that happened, they just took for granted that everything was kosher. A week later one of the testers noticed a strange bug in a part of the product that hadn’t changed lately. Or had it? We spent about a day isolating the bug, and then took all our information to a developer. There was no card in our bug tracker, and no PR notes, and no new tests, so of course it was a pain to track down.

That quick fix on one persons spare time ended up taking a day or more of time from a few people to discover a bug, isolate the problem, and then research where it was coming from.

Today we like to get software done with as little ceremony as possible. If we see something wrong, or notice missing scope on a feature request, or maybe if there is a test that could be written, we like to just get it done. This process feels fast and easy, but it never is.

The process we use in software development constrains and constricts the flow of code. That is a good thing and is one of the many ways we control for risk. Every change we make to a bit of code has the possibility to introduce a new problem. Every code change we don’t talk about has a guarantee of introducing a new problem.

Low ceremony is cool. But, it only works well when people are willing to discover the right amount of conversation to have in its absence. Otherwise we have hidden risk that will inevitably be discovered at a bad time.

 Comment on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: