The failure of technology to treat the problems - a conversation with Adam Thier
- Summary:
- Adam Thier uses his experience to talk about the modern myths that contribute towards making software bad.
I've known Adam Thier, CTO PICS Auditing for a number of years. We've collaborated on a few things, swap ideas, and, on occasion, put the world to rights. Last week, a mutual colleague of ours waxed lyrical about a customer who has decided to keep business critical applications in their proprietary state but that everything else is going forward in open source.
At the time, I was curious to know how all that open source 'stuff' was going to get glued together because as we have seen many times in the past, open source is great at one level - who doesn't want free? But in the commercial environment, someone, somewhere has to go figure out how it all gets stitched together. This is the world of the System Integrator who loves nothing more than to hear this kind of conversation because he/she knows this means bums on seats. Thier was far from impressed with that idea and so I got him to come on a Skype call with me to discuss the topic.
Thier speaks with authority on this topic because he is slap bang in the middle of making big decisions about his company's software landscape. Recalling his college experience, Thier argues that
Ninety percent of the time, people spend treating the symptoms and not the problem itself. The problem is that they take on truths that don't exist because there are no truths in generalities.
Sound familiar? It does to me and was something that we tackled at diginomica as it relates to our code. Not that these decisions are easy. When you have an ageing set of code that's getting the job done but doesn't feel quite right then the temptation to keep patching or adding the latest do-what is tempting. But there comes a time when you have to objectively stand back and consider drains up work.
Thier debunks many off the fashionable trends that have emerged in the last few years on the grounds that the vogue for things like micro services run the risk of treating symptoms rather than addressing the big problems. He then goes on to talk about how 'agile' was developed because engineers were sick and tired of the distance that grew between developer and the customers but that in recent times, the techniques surrounding it have been bent out of shape in some places so that 'agile' has become synonymous with fixed period sprints that may - or may not - end up with properly functioning code. I get that one too because as I said to Thier on the call, development isn't done until I've got what I want, not what the scrum master throws over the wall.
This provides a lens through which to consider how enterprise developer shops operate in the context of pressure to build consumers applications that have minimum viable capability. I've argued in the past that doesn't work yet we see that a lot. So what is the solution?
Establish the vision and then start at the bottom, not in the middle somewhere. And do a lot of math.
Enjoy the conversation.
Image credit - head shot via vbprofiles.