Technology - who cares?

not-every-problem-with-code

I'm a geek. And, although it pains me to admit it, one who's firmly in the realms of middle age. I'm one of those people who will occasionally bang on about writing code on his ZX Spectrum back in the day, typing in programs from magazines and generally being ostracised in the playground.

After university, I was lucky enough to fall into a career where people pay me for doing something I'd do in my spare time anyway. I get to build software for people, and now and again I get to work on a project that almost everyone I know has heard of. It's great.

After a while building software, I came to a realisation that every developer has to deal with at some point: you can't solve all the problems with technology. Some of them need to be solved by changing underlying business processes, educating people, or some other process. This realisation ties in nicely with a question we ask a lot at earthware: Why? Why do you think you need this? Why is software the solution? Have you considered doing X, Y, or Z?

Whilst it's unusual for a software development agency to challenge the very reasons they've been brought in to a client in the first place, we have found over the years that making sure you've got a good reason for being somewhere is a pretty important first step in the sort of long term relationship we look for.

Our job is not to build software; it's to help solve our client's problems. Everyone who wants a technology solution of some sort wants it for a reason, and they are normally reasons like these...

  • Increase sales
  • Improve customer engagement
  • Identify patterns in my data
  • Streamline business processes

... to name just a few.

There's always a reason and in our line of work, 99.9% of the time that reason has nothing to do with technology. Understand that reason, and the chances of your project succeeding have increased exponentially before a single line of code is written.

And with that in mind, here's a fact:

Most of the time, the client does not care about the technology. They care about the solution.

If you ask them what's important, you will almost never hear "written in React" or "it has to use Redux". In larger organisations you might get a direction towards Microsoft or Java, in smaller ones you will be pushed towards cheaper options, but as long as it works and will still work next week, month or year, they don't care.

This is vitally important to remember.

ioc-wars

I've worked on projects where people have spent days debating and performance testing different options for IoC containers. The reality is that if your project doesn't go well, it's not going to be because you chose the "wrong" IoC container. If you have to spend more than 5 minutes on that kind of low level decision, you're not adding value to your client.

So given all that, what's the point of this post/rant? Am I saying there's no difference between Ruby and .NET, between Angular and React, that there's no point bothering to learn anything different from that which you already know - that yesterday's approaches are as good as todays?

Of course not. In every good developer I know, the desire to learn and improve is strong, and learning different languages and ways of doing things is important to our progression. Further to that, with new technologies can come new ways of thinking, better ways of solving the problems and making sure the solution is robust.

However, when starting a new project, the choices we make on how we build and what we do it with shouldn't just come down to "what's the latest and greatest", or "what do I want to learn today." It should always come down to "what is going to benefit the project the most". Is adopting a new framework going to deliver benefits that outweigh the cost of learning how to build more than a to-do app? If I decide to use Dart, how am I going to offset the problems that will cause when we need to support it later and our support person only knows C#?

classic-asp

There's also another angle to consider. As an agency, we need to make sure we stay current with technology. But this doesn't mean we need to build every project in the absolute latest cool tech - down that road lies madness (for the people who have to support all these things) and less profit (as we lose time on working our way through the challenges involved in adopting new things). It does mean adopting new technology when it makes sense to do so. It also makes sense that as a business, we adopt a core technology to work in - at earthware it's .NET. It's not that we can't do Node, Ruby or whatever else, but by choosing a core technology we have amassed an extremely high level of skill in this area and this enables us to better deliver the things our clients value.

So when would we adopt something new?

  • When it makes sense for the project - the business requirements mean that we need to use something a bit different, or would be easier to achieve if we used new or beta software.
  • When we are happy that it will be relatively low impact or easy to back out of if it doesn't work

Following these rules allows us to make good decisions on our projects - and then, when we feel like it, we can re-invest and do some really interesting stuff.

Technology decisions are, as with everything else, a balance. When making them, we always need to come back to the question "Why?" And if the answer doesn't involve any kind of benefit except to the CV of the development team, we need to challenge ourselves on whether we have made the right decision or not.