In software development, there is only one thing that you have to focus on to get it right. One single aspect that really makes a difference.
Everything. Every single thing. The whole.
The holistic view is about the fact that everything matters. There are many people and companies that focus on a given technique, a given system or even a single supplier and roam around to their customers with their golden hammer trying to convince them that their problem is about nails.
It is very seldom about nails.
By focusing too much on a particular technique, product or vendor, you miss the holistic view. Everything matters. Architecture matters. Design matters. Process matters. Communication matters. Technology matters. Programming languages matter. Every line of code matters.
Anything but a holistic view of software development stands a good risk of leading to random sub-optimizations. Doing any change to the ecosystem of code, developers and stakeholders is actually just like optimizing software. If you don’t understand how bottlenecks work and what the real bottleneck is, your optimization efforts are sadly likely to be fruitless. That’s just the nature of bottlenecks.
So how do you find the bottleneck for a team developing a software system? Unfortunately, creative work can not be measured in the same way as a running software system. We can measure trends, but we do have to have a deep understanding of the nature of software development to be able to find and remove bottlenecks.
To become good at finding bottlenecks, you need to cultivate a reflective mindset and be prepared to invest a lot of time and passion to develop both a breadth and a depth of everything related to software development. Without the holistic view, you will optimize something that’s not the bottleneck. And that’s waste.
In other words, to get the intended effect you need to understand and care for everything; the different qualities of your codebase, the design and architecture of the system, the skill-set of your team members, what makes your team members tick, how you actually work together and how you work with your stakeholders. All this combined leads up to the speed and cost at which you can produce quality software that will cope with change. But the bottleneck, whatever it may be in your particular case, will be what limits your throughput.
Does acquiring a holistic view of software development seem like Utopia? It’s not. It does however require people with a true passion for software development and a determination to grow a continuously improving skill-set in a wide range of areas (and if you know people who dream about working in an organization where these values are core values, you know where to send them).
Many persons in advisory positions are no longer practitioners themselves. Their real-world knowledge degrades quite rapidly in a fast moving business like this, and they end up being kind of one-dimensional. Either they say that the most important thing is the process or they may say that a particular type of design is the solution to anyone’s problem. This is risky business. Software development does not work like that. Again, it’s all about bottlenecks.
Let’s say that you get a process consultant on your team. He or she may very well succeed in improving the way you do iterative development and hopefully even improve the communication in the project. That’s a good thing, isn’t it? Sure, it’s a good thing. But you might not get any effect out of it, even if it’s done right. It all depends on the bottleneck.
What if the real bottleneck is that the codebase is hard to work with? Will the process person who never wrote code or lost touch with it understand that? Of course not. Even if they would suspect it, can they do anything about it? Can they help you remove that bottleneck? Will they tell you if they suspect it? Giving that advice may mean that they themselves will be replaced by another type of consultant. Can they see if you are wasting even more resources because of design problems? No, they can’t. And they end up barking up the wrong tree for your particular team, product and situation.
The opposite is of course also true. You may bring in a consultant on a specific technology that will help you be more productive. They will very likely succeed in implementing the technology. But did they succeed in transferring skills to the employees that will live with the system? And even if they did - did applying this specific technology solve the current bottleneck? If the bottleneck actually was related to team communication, well then you at least have a new shiny app server or something, but you’re still not producing a valuable, high-quality, evolvable system faster.
You can almost physically feel when you work in an environment where the holistic view is not payed attention to. It’s hard to get into flow. The code base is hard to evolve. A constant stream of small technical and organizational annoyances is a common symptom, and just a general feeling that everything is a bit cumbersome and slow.
If you’re lucky, you may have worked with a system that was the opposite. Everything felt smooth, the code was clear, the abstractions were right, the team had flow and it was easy to be productive and evolve the system. And if there was an annoyance, it vanished as fast as it got there.
Is the existence of environments like this just a coincidence? Not according to my experience. To get there, you have to see the whole. You have to understand how flow works and you have to be careful of anything that disturbs the flow - on all levels of detail. It’s scaringly easy to degrade the performance of a software team severely.
Unfortunately, most software development organizations suffer from this, but an even more unfortunate fact is that they are seldom aware of it themselves. They work hard and because of that, they believe they’re actually going at their full potential, but their actual potential is usually quite a lot higher than they are aware of.
What you can do is to cultivate your holistic view of software development, pay close attention to what you do, how you do it, study how flow works and how productivity works for knowledge workers. You will begin to understand how even small, seemingly uninteresting things reduces both your short-term and long-term productivity.
If you succeed, you will most likely be surprised to find at what rate you can actually develop the same - or a better - system. It’s hard work, but it’s crucial, economic and definitely worth the effort.