If you have been involved for software engineering for any length of time, you soon realise that there is a lot more to software than just the end product. Despite the efforts of many to try and turn the development of software into a turn key process, there is still an evident ‘gap’ between those who do software engineering as a pure science and those who bring more ‘softer’ skills to the table & think about the bigger picture.

The trouble is (if it is indeed a trouble) is that software is mostly used by people, and most of the software development practices usually try to account for this by the concept of ‘actors’. You all know what I mean, the ‘profiling’ of users where fictional people are created (Female, blond, 30 something into cats, drinks short black coffee first thing in the morning and is very afraid of spiders… I kid you not) to help those designing and developing software to better think about the end user – as they say at Atlassian “don’t screw the user”. Now to a certain degree, this is a wise approach, a pissed off user is not a desirable outcome – without the user, there is isn’t a market for your software and you are dead in the water.

But, and this is a big but – there are many types of users of a piece of software and they aren’t all external… Some of the most important users of your software sit right inside of your software business – the developers!

I would argue that the developers are just as important as the end user – happy productive developers produce well engineered and well considered software. Oddly enough there is a lot of overlap in the requirements between the end users and the developers:

• Both want stable and well behaved software – nothing worse than trying to develop or use a piece of software that is as about as stable as piece of jelly in an earthquake…
• Both want software they can understand and apply safely – real developers do not want to modify a rats nest of complex code that gives them headaches.
• Both want to gain efficiencies with the software – the bigger the leverage the bigger the performance gained.

If you can design software and think about the end users and the developers who have to develop it – you will be a long way to beating out on your competition that does not. Great software systems that consider their developers may start off a little slower out of the traps but in the long term they gain a massive head of steam in sheer speed of quality execution – this is something more than unit tests and automation – it’s a development mindset at play that separates good from great.

As for how to identify such systems when you see them, well it’s hard; but a good sign is the software is just ‘accepted’ and ‘de facto’ – it gets on with the job without fuss or undue duress – it’s a natural aid that supports rather than annoys. Often it will have a supporting community that has just grown around it without being ‘forced’ – great systems attract great people; which is a massive plus, as it means such systems get the best feedback possible – further enhancing their lead against the competition.

So, in conclusion, it’s not enough to have a laser like focus on the end users, you need to ‘feed your techies’ and make sure they have the resources and time to build development leverage into the end system. This way everyone wins and keeps winning.