According to Gartner, the value of the worldwide enterprise software industry in 2013 was around $410 billion. More recently, it’s likely that the total enterprise software revenue reached above $700 billion in 2015. That’s only for enterprise software. Please don’t worry that these amounts might not be precise, the point I’m making is that the software industry is massive and is probably the fastest growing industry in the world to date.
It’s no surprise that software development is such a hot and ever changing space. In the past 30 years we’ve experienced a boom of software development methods. Just take a look at this list from wikipedia. By the way, there are some gems to be found there, such as "You aren't gonna need it” or “Worse is better” :).
I’ve been in this industry for last 10 to 15 years. My primary interest was always to build great software products, and at the same time I have never focused on, or really cared about, software development itself. Let me explain why.
I find a good analogy to software development in what Henri Poincaré said - “Sociologists discuss sociological methods; physicists discuss physics”. If any sociologists are reading, please don’t take offence. I’m recalling his words just to highlight what’s most likely happening in the software development industry.
We should all build great products, not obsess about software development and it’s methods.
I’m not exactly sure what really happened, but somehow software development became the thing in itself. I guess that this has mainly been propelled by the fact that there are many more people who want to build software products than there are people that know how to actually do it. That put a market value on those skills, and forced software development to become a marketable and sellable “product”. I feel that a big chunk of our industry is now focused on software development and software development methods instead of pursuing the creation of value for customers. I don’t mean that excelling in your craft is not valuable. The opposite. I’m sure it is essential, but the primary reason is the value for the end customer.
Software development has been taken out of the customer context. A great example for that is how the original postulates of the Agile Software Manifesto can be misinterpreted.
As I really respect the manifesto and what it contributed, I’m surprised that it actually does not mention the customer in it’s core. The customer shows up only in the principles behind the Agile Software Manifesto. But let’s look at the core postulates and common misinterpretations that I observe.
1.) Individuals and interactions over processes and tools.
To start with, it really depends on so many things, like the size of the presented problem, the size and structure of the team dedicated to dealing with it, etc.
More importantly, it does not mean that processes and tools are not important. They might be - sometimes they are and sometimes they aren’t. For instance, they are critical when you operate on a large scale - for example, involving a big team with multiple interdependent tracks.
What it means, though, is that individuals and interactions are more instrumental for the success of your delivery, hence you should put more emphasis there.
2.) Working software over comprehensive documentation.
I’m trying to understand why anyone would want to have comprehensive documentation and a product that simply does not work. C’mon, kind of doesn’t make sense, does it?
Yet so often I hear this used against writing any documentation. Try effectively working with a product developed over several years, one that has, let’s say, 1M lines of code and zero words of documentation. Impossible.
3.) Customer collaboration over contract negotiation.
Some are just so obvious that I find them funny to go through. So I’m going to skip this one.
4.) Responding to change over following a plan.
And finally my favourite one.
It is an argument for being logical, reasonable and having common sense. If there's new data that was not available before, be open to adjusting your plans. Otherwise you are going hit the wall called reality. Yet this really does not invalidate the need for amazing planning.
This pseudo logic goes like this: it’s very easy to discard planning, for instance, and focus only on responding to change, claiming that there’s no point in planning as plans never run true. So let’s be agile and respond continuously to change, and we will see.
If you disconnect software development from its context - which first and foremost is the customer, but also the money and time that place heavy constraints on everything we do - it’s really easy to arrive at such superficial and naive conclusions.
Adding the context changes everything. You are building value for people most likely because you want to get some value in return. Meaning you are building a business. Your customers want to get the best product for the most affordable price in the shortest possible time. You have limited resources - time and money - to deliver all that to your customers. There are others fighting for the same customer, continuously thinking about how can they do things better, faster and cheaper than you.
Now try to satisfy those requirements of reality without aggressive business goals for which very often you need to invest a lot (e.g. to build a product). Even more, try to meet those business goals without detailed planning that accounts for time and money constraints. In no time you are going to find yourself out of business, as you will most likely simply run out of resources.
BTW, those constraints present great opportunities, as whoever figures them out better than anyone else will win the customers.
I personally like to come at software products development from an angle other than software development. I see it as a design problem, which gives greater perspective on what you want to achieve. Most importantly, it never ignores the context, for context defines the problem. This part deserves a separate post, so I’m not going to go there right now.
“Notes on the Synthesis of Form” is the best book I have read so far on the subject of design, and it is completely applicable for building software products or actually for solving any type of design problem there is. Highly recommended.