No, it’s not Agile methodologies, Ruby on Rails skills, or Test Driven Development.
It’s communication.
I’ve talked about this before from different angles, but I continue to believe that (mis)communication is the biggest issue in IT.
It is certainly important to have a good grip on the technologies you need to use, but if you have colleagues, customers, or users up in arms because of something they (mis)understand about what you did (not) communicate to them, it’s all for naught.
A small example will illustrate this. Recently I had time to review some of the work output of one of my subcontractors. I noticed on more than one occasion that he was optimizing his work for minimal billable hours. Considering this, his accuracy was quite good, but there were times when he would complete a task in half an hour that I would have spent a couple of hours on — or, more exactly, upon reviewing his coding, it needed a fair bit more TLC to truly be fully tested, stable, resilient and maintainable. In fact, the very reason I had started looking more closely at his work is that it has begun to develop a reputation with myself and others in my organization, as rather fragile and difficult to maintain over the long haul.
It turned out that he had assumed that it would be a Bad Thing to take “that long” to complete these tasks — I would imagine because he’s been on the wrong end of some unrealistic expectations from other employers during his career. For various reasons I had never told him it was okay to do the job right because I assume he Just Knew That. Now that he has my explicit permission, the quality of his work output has risen accordingly. It’s sad I had to give him permission to do good work, thanks to the headspace that many tech employers inhabit — but that’s a whole other post.
Here we had a failure to ask questions on his part and a failure to close the feedback loop on my part. In other words it was all about communication and very little about technical issues. It reminded me yet again that development is about clearly understanding the requirements — which means they have to be clearly defined and explained. It’s a truth we can’t be reminded of too often.
