The engineering response

Recently I submitted an issue for a software project. It was something like “The column for total shows NaN when it should be a number” and a bit of speculation about why this may be happening.

Turns out I was wrong with why it was happening and the issue was caused by something else. It was closed within minutes of being opened with the response “The server was restarted and had to resync. When it’s finished resyncing it will display the right value.”

This is an engineering response.

In contrast, a quality response is slightly more useful, and follows roughly this pattern: “This is feedback. Something in our product has not met their expectations. What is it that didn’t meet their expectations? How can we change it so it would meet that expectation?”

Blaming resyncing is not a resolution to the issue. The real resolution to the issue is handling resyncing in a way the customer would expect. But the engineering response doesn’t seem to understand this (or maybe just doesn’t want to understand it).

‘Feedback’ is a very different pigeon-hole to ‘issue’ to an engineer, even though the two classifications often overlap. The excuse for not treating this issue as feedback is likely to be ‘this was submitted as an issue, not feedback’, and that’s all the justification that’s required. But doing so would be yet another engineering response.

How about responding instead with “Change the table to from NaN to Resyncing, please wait if resync is happening”

That would meet the expectations of the user.

But the engineering response to making a change like that would be “Now we need to add a module to detect whether or not we’re resyncing, and we have to add logic here and here and here, and sometimes the resync detection fails because of this, and we have to refactor these modules, and then …” on and on.

Nobody cares.

Engineers should meet customer expectations - that’s why engineers exist. Find a way.

Postscript:

The lesson from this rant is something about attitude, about culture, about perspective and context. It’s probably best to leave it like that, without concrete definitions.

Also customers and engineers need to be specific about expectations, which is often the hardest thing of all.