Why Software is Hard

I came across this article by Jesse Watson thanks to a friend. It is an excellent, thorough analysis of the pros and cons of distributed (remote) development teams, but more than that it describes the process of building software (and why it so often fails) as well as anything I’ve ever read. Below are some highlights along with my editorializing. I hope you get as much from this as I did.

On Deep Context

“The most valuable asset in the software industry is the synthesis of programming skill and deep context in the business problem domain, in one skull.”

I agree with this 100%. It is getting increasingly difficult to bounce around between different technologies and domains. The complexity of the products now being built, and the level of sophistication required to build them, is on a steep increase. The need to go deep not only on the technology, but how that technology applies to the business problem of a given company, is an invaluable skill.

I think we’re getting to the other side of developing simple technology. All of that is being automated, as I’ve written about many times.

On Micro-Problems

“Most of the time is spent thinking and communicating about a seemingly endless number of micro-problems (emphasis mine) that seemingly emerge out of nowhere, and constitute the real territory between the technology and the business problem. Part of traversing this landscape of micro-problems is inventing, communicating (emphasis mine), and internalizing a plethora of named and unnamed abstractions. It is the only way to break down the complexity so you can grapple with it.”

This is perhaps the most important point of this entire article. Building software is a never-ending decision matrix that is always being informed by new information. The problems that development teams solve every day often “emerge out of nowhere”, as Jesse says, because the ground shifts every single day (or so it seems / feels like).

I also wanted to highlight his point about communicating effectively during the process. There is nothing that kills money and time like bad communication. Fostering an environment where you can revisit the same problem over and over again in order to arrive at the right decision is incredibly important.

On Remote vs Local

I think this is a bit of a miss. Yes, it’s perhaps better in some parts of a project if everyone’s in the same room thrashing away at it. However, being in an office context is often filled with interruption and spending time on things that have nothing to do with getting the project done. The debate is one of deep context vs. shallow context, not local vs. remote. You can achieve deep context while still being remote. I’ve seen it work too many times.

It’s a decision more than anything else.

Conclusion

In the end, you have to make your own decisions about geography. Regardless of geography, however, you should only have developers on your team who can offer the kind of deep context this author talks about. Developers should be able to understand thoroughly the business domain and always be thinking about how their work affects the business, not taking a spec and building it blindly.