When developers fix a problem, they like to show off a little.
We like to wax lyrical about the intricacies of the system we are building, or the tools that we’re using, or the techniques we’re employing. We’ve worked hard to learn something and we want a pat on the head from the user. We love to hear ourselves explaining things! Perhaps this is where the whiteboard conversation comes from? While we may not like doing presentations, we do like to stand up and show off our knowledge in front of a select group of users and other developers.
So, is collaboration actually important? Isn’t it better to just fix the problem and move on? Does everyone need to understand all the nuances?
Not all the time, that’s for sure. But sometimes we do need to pay attention to details. So how do we know when something is important?
When you take your car to the garage to be fixed, for the most part you don’t care about what’s being done. Only if something important and expensive breaks do we need to get involved.
The point is – building software systems is an abstract pursuit. There is nothing physical to interpret other than end results. This often requires imagination. Visualisation can sometimes be helpful, however, just like words, visuals are open to interpretation.
So how do we really know what we are getting in a piece of software?
The only way we know. We test. We make sure the thing does what we are told it does.
And how else do we make sure? We take an interest in what’s going on while it’s being built.
Oversight and testing. Project management, good testing.
As users, let’s take the responsibility for both good oversight and good testing. Then the developers don’t have to explain how it works, or we can let them and feel assured that we know that the system we have, is the one that we asked for.
And in our heads we can say “Don’t explain it, just fix it” and the developer can feel confident that they created what we originally asked for.