Focus

So, you’ve got a large team of talented programmers, a problem to solve and some people with an understanding of the underlying domain details. What now?

Any big job needs to get work done in order to be successful. Any type of constructive effort needs that completed work to be brought together into one large coherent piece. In this, software is no different than constructing buildings, bridges, machines, paintings etc. The raw man-power alone is not enough to be successful, the effort must converge on a final by-product. One that makes sense.

If you ask twenty different people their opinions, you’ll get twenty different answers. If you let twenty different artists produce work, you’ll get twenty different styles. Sometimes that is a good thing, but when, in the end you’re looking for one consistent piece -- not twenty -- that can be a huge problem.

Even where there is little latitude, it’s hard to get a couple of people to precisely agree on the same points. Sometimes there are individuals who sync up; get on the same page, but that is a rare occurrence. We are individuals and to some degree, we are all unique. It’s precisely because of this fundamental aspect of human behavior that pretty much if there is a desire for consistency, then the flow needs to be focused by a single individual. This is true in leadership, design, art and anywhere else that rests on making a series of choices. If it can’t be spelled out right down to the details, then any degrees of freedom involve trade-offs, and if there are enough of them, everyone will choose different options.

It’s easy to see examples of unfocused work in software. From the interface level, there may be a huge amount of functionality, but it is haphazardly scattered all over the interface. Without extensive guidance, navigation becomes a major obstacle to usage.  Unfocused tools are ugly, frustrating and annoying to use, even if they work properly.

At the operational level, the system might be installed, but keeping it running or upgrading it to the next version is a nightmare. Magic, undecipherable incantations are required at unpredictable intervals in order to restore some semblance of a working state. Thus necessary maintenance gets hampered by fears of just making it worse. Rust settles in.

At the coding level, the only hope of fixing problems or extending the functionality in an unfocused work comes from just slogging through the details one-by-one. But because there is no boundary to how much could be effected, there is hesitation to start. As the problems get worse, the likelihood of finding someone with enough patience to deal with the problem decreases rapidly. Thus the problems get ignored as they grow and propagate through-out the system.

What a large team of talented programmers needs is someone to bring their work into focus. What a problem needs in order to get solved is for someone to bring the scope of the work into focus. What the domain experts need is for someone to help them focus on which aspects of the problem need to be addressed, and in which order. Without focus, the work will become a blurry disaster, gradually getting worse with each new attempt, not better.

While the necessity of focus is obvious, there are always those who feel that having some other person handle it, limits their freedom. We are awash in attempts to distribute this control out to the masses to make the work more appealing, but while these ideas may be attractive to many people the consequences of their usage should not be. Is it better to go wild on an unfocused project, then to be constrained by a focused one? Maybe not in the heat of the moment, but certainly contributing to a large number of unfocused failures starts to eat at one’s own self worth. What good is a masterpiece if it is buried in the mud? Some people work purely for money, but for anyone that cares about what they do, it’s the ultimate success of the project that matters most, nit their freedoms. And to have any chance at success, the project needs focus. Trading freedom for the possibility of success is an acceptable cost.

And thus a project, particularly a software one, needs someone to bring it into focus. But this is no easy task and requires a vast amount of real-world experience to understand the subtleties and costs of the various trade-offs. It’s more than just knowing how to do the work, it’s also about knowing what to avoid, where the problems come from, how to fix them and how the work fits into the environment around it. Focus comes from practical experience. Lots and lots of it. But the software development culture has been particularly good at ignoring this, and as a consequence a massive number of the development efforts have died, or are limping along in barely usable states, gradually getting worse. It’s a lesson we seem destined not to learn.