As software developers we inherently like to be challenged in our everyday work of writing kick-ass software. We like to create and innovate. We want to build the best thing with the best technologies we have at our disposal.
However, sometimes it’s difficult for a developer to realise how to get to the end goal of a working solution. So the business tries to help by breaking out a bottle of the Agile spray solution and spraying it over their developers, resulting in more features faster! That’s how it works… right?
Well, I’m afraid not. A lot of us create an emotional attachment to the software we write. As a result we may spend a lot of time focusing on the quality of the software, rather than the value or impact it brings to the end-user or client. Or we may spend a lot of time doing analysis and research. Or we may spend time on one of a dozen other unnecessary tasks. Software engineering has become like construction engineering, the bigger the building or the software solution – the more valuable it is. You could think of this as outputting more story points or lines of code.
I recently heard a great analogy from Dan North describing similarities in surgery and software development. Dan put forward an example of someone who may go into a surgery and explain that they have a pain in their side. The surgeon might look at the patient and think, that’s appendicitis! So the patient may have two options;
- The surgeon makes a small incision to investigate and solve the problem or
- The surgeon opens out a large hole, solves the problem and stiches up the patient.
If you were the patient, which option would you go for? The surgeon might choose option 2 because they know they have great stitching skills and the procedure might take more time and cost more money. But, a good surgeon might schedule in a scan, only to discover it can be solved by non-surgical means, as it was only trapped wind. These are the best surgeons.
Applying this to software development, the idea is that we should be focused on outputting less lines of code or even no code that will result in value or impact. Like the surgeon who is an excellent stitcher, you could be an excellent software developer and write beautifully crafted code. But if you could solve the problem with as little or even no lines of code, you will have no bugs – the equivalent of faster recovery time in our analogy.
As I have mentioned, we need to get away from this emotional attachment to software. With the movement to micro-services architectures, this couldn’t be further from the truth. We’ll be building our throw-away architectures, applications that might be replaced one year down the line. At another talk by Dan North, he described a time he wrote this magnificent application that he was so proud of and he couldn’t wait to show it to his mate. But when his mate saw it, the first question he asked, was “Is it live yet?”
This made him realise that it might be all bells and whistles, but until it’s in front of the customer, we won’t know the impact or value it creates. Sometimes we come across poorly written applications were we may laugh and joke about not obeying DRY or SOLID principles. But at the end of the day, if it is doing what it is purposed to do in production, how much does that poor design matter? The best software developers are those who can create solutions with the least amount of code.
Measurements of success should be agnostic to the number of lines of code output. Measurements of success should be agnostic to the number of story points output. Lines of code and story points do not tell you how much value they bring to the customer. Having it live and providing feedback demonstrates to you the value you have created, focusing on delivery of software faster through the least amount of procedures or code will get us there.
Thanks for reading and keep building awesome.
Until next time!
Ian B
P.S. You can also find me on Twitter: @ianaldo21
Ian Barry 