I am feeling a little existential and metaphorical today, so forgive me if this post has more than just a slight tinge of existential metaphor about it. I do hope it still makes some sense.
There are two fundamental ways of looking at software development. One is all about the final product and the direct benefits you can get from it. The other is all about the lessons you learn from the process of building the software. I call them software as a destination and software as a journey. Historically speaking and even into the present day, the majority of companies that build any kind of software are ‘software as a destination’ companies. They want to extract some direct financial benefit from the software they build (which is fair enough), until this benefit is realised, the process of building the software is just a resource (time, money) drain. On the other hand, most individuals who build software for those companies would instinctively like to be (and in many cases ARE) ‘software as a journey’ people. We want to enjoy our work, we want to learn as much as we can, we want to interact with those around us, we want to build code that we can be proud of and we want to get paid. All of this will happen throughout the project rather than just at the end, and so it is all about the journey, the final success of the product is almost icing on the cake. It seems that there is a fundamental disconnect between what a company wants to get out of building software and what the developers will try to extract from the experience.
This is why the software development industry is in a sort-of screwed-up state, or at least it has been for many years (things are getting better). Companies see the destination and want to arrive there as quickly as they can, the sooner they get there the sooner they see the benefits from all that money they spend and the sooner they can start getting their money back, either directly or indirectly. Anything that stands in the way of this goal must be swept aside and this includes the developers who want to enjoy the journey and ‘smell the roses’ on their way to the final product. Of course, the companies hold all the cards (they employ you, pay you – which indirectly, feeds and clothes’ your children) and so can usually get their way if they really want to. Developers can try to make noise about the value of paying attention to the journey, but if the company is dead set on doing things their way, that’s the way things will be done, developers can either fall into line or there will be other developers to replace them. However, just like a real, physical journey, if you have your eyes set firmly on the destination and are not looking where you’re putting your feet, there is a good chance you will trip over some roots, or a snake will bite you, or you won’t notice that cliff which is right between you and where you’re going. This is how we get failed projects.
Once the project and the company are at the bottom of the cliff, you can kinda tell that everyone is in trouble. But it is difficult to figure out exactly how you ended up where you are, you had your eyes firmly on the destination and forgot to pay attention to what was happening around you, so it is hard to pinpoint the mistakes that landed you at the bottom of a cliff. Companies will do a post-mortem, come up with some vague reasons for why things went to hell, everyone feels better that they have an explanation (leaving everyone none the wiser in reality). And so next time they go out and do the same thing all over again. All the while, the answer is staring everyone right in the face. If only they had listened to the developers who told them to pay attention to the journey and not worry so much about the destination things would have been different. Even novice programmers soon learn, from personal experience, that when we slow down and pay attention to what we are doing right now, we get a lot more out of it, we learn more and the final product is improved as a result. There are only benefits, no downsides, alright, you lose some time in the short term, but gain it all back with interest in the long term. But, at the macro level where committees make decisions, this same lesson takes years and decades to permeate the hive-mind. Not to mention the fact that seeing only the destination is much easier than constantly paying attention, and so even the occasional developer gets seduced by the ‘software as a destination’ mentality (it’s really more than just the occasional), which sets everyone back by introducing conflicting opinion and muddying the waters unnecessarily.
There was a bunch of people who were all ‘software as a journey’ people who basically got sick of all the back and forth. They recognised the fact that the journey is what really matters not just at the personal level, where each individual developer is concerned, but at the team, project and company level as well. They decided to give a united voice to the message that as long as you take care and extract the maximum benefit along the way, the destination will take care of itself – you will arrive somewhere you want to be. It may not be exactly the same place where you thought you would end up, but it will be a nice place nevertheless and best of all, you will have a very good idea of precisely how you got where you are, despite not having a narrow focus on the final objective from the start. More like-minded people joined the initial bunch and the movement got more organised. Some of these people started companies of their own; others brought their message to larger organisation. And now that the ‘software as a journey’ message had a united voice (albeit still a comparatively small one), the success of looking at software development this way could be demonstrated, but more importantly, disseminated to the industry at large.
It is a major undertaking for a company to develop any significant piece of software. Not just from a financial perspective, but as far as airing out the dirty baggage and discovering the process inefficiencies that every significant company will have. After all, in order to put something logically into code you need to figure out exactly what that something is and how it works. This is a golden opportunity for the company to streamline and improve how their business works, figure out if some processes are unnecessary. You’re building software, but you’re paying attention to what you’re doing not just at the technical level but at the organisational level as well. As a result, not only do you get more robust software that better fits your needs, but you also improve the day to day operations of the company; all because you were paying attention to the journey rather than focusing on the destination.
But, it is so much easier to simply look towards the goals and on paper it seems like it SHOULD be more efficient. If you’re in management you want to seem more efficient and focused rather than being wishy-washy and touchy-feely, preaching self-awareness and a less-rapid pace just isn’t strategic enough. And so companies create artificial deadline pressures (like end of financial cycle of some sort), to make everything neater and make the people in charge look good and it feels like for every step the agile movement takes towards running software projects better, some company somewhere, takes two steps back.
Robert A Heinlein once said:
“The supreme irony of life is that hardly anyone gets out of it alive.”
Infact, he had many other quotes which I think are quite relevant to the software profession, maybe I’ll do a post about that at some point. To me this quote says that it’s the moment that really matters, enjoy the life you have now rather than constantly looking forward to something better. I am not sure if there is any irony to be found in software, but if you direct all your focus towards your goal without paying due attention to the nitty gritty of what you’re doing every day, you’re likely to not get any useable software out of it. As long as you have a reasonable idea of where you want to end up, you just need to get the details right and the bigger picture will tend to sort itself out. On the other hand, you can have the clearest possible goal in mind, but if you let the details slide, bad things will almost certainly happen.
Images by Norma Desmond and alicepopkorn