Innovation in Software

I’ve been thinking more about building windmills recently.

I know quite a few musicians. Some of them are mildly successful getting regular royalty cheques and making a living. Some run nights at clubs or bars that supplements their main income, steadily building their profile. Others are failing at making money and struggling to work out what to do to fix it. The difference between them is what they hear when somebody talks about “the music business”.

The successful ones hear the word “business”, the struggling ones the word “music”.

It’s the same in the software business. We grow up as developers, loving the experience of writing code and learning how to do incredible things with nothing more than our minds and a piece of commodity hardware with a free language compiler or interpreter installed. It’s liberating, it’s creative, it’s what we decide we want to do with our lives.

Except the software business is a business. It’s there to serve client needs, not the needs of software or artistic expression. Not enough people seem to grasp that – they seem stuck in the mindset that by producing code, they’re running a software business. It’s taken me several years of running my own company to finally see this for the lie that it is.

Imagine an architect firm where all the firm produced was building designs that nobody wanted or needed. Imagine a firm that only worked on concepts that nobody had asked for, or on receiving a client brief they threw it in the bin and just did what they felt was “better”. Right now, that’s what a lot of software firms are looking like: and like that fictional architect firm, they’re going to struggle to pay the bills.

Client need, user expectation, it’s all this industry is about. It’s the main thing we should think about. We’re not in a university lab playing with data structures and algorithms any more. In the same way architecture is about understanding a brief and imagining solutions rather than drawing, so software development is about listening and understanding more than it is about writing code. Sure drawing is important to an architect, and writing code is important to a developer, but they are an output of the real job not the job itself.

I’m not arguing there isn’t a place for understanding better code, or producing beautiful projects, merely that such activities either need to take place outside of an industrial setting or should at least not conflict with the business needs. It’s OK for an architect to produce beautiful buildings that are also functional, so it’s OK for a programmer to produce beautiful code that also meets client needs: it’s just that client needs should come first on both occasions.

And if you like the idea of development as akin to architecture, or you are struggling to see the parallels, you may want to read this article written nearly two years ago. We should look to the architecture industry way more than we do right now, and we should all use Ruby way more than we do.