The Risk of Believing in Easy Software Development

There are fields like medicine, research, construction and entertainment where its widely excepted that any one project will be difficult and you do the best we can with the process and technology available. Then there are other fields like manufacturing, farming, education and software development where more predictable results are expected.

Right from the beginning of software development there were “No Silver Bullet” papers explaining the difficulties of the industry and why star software developers would have to be treated as such. The battle lines have shifted since then - its relatively, mostly agreed now that you will need highly paid, experienced software professionals or risk project failure. The problem now is with a perception that if you hire the right people and follow the right process you are done and risk should be minimal.

That perception is the current biggest threat to successful software development. Instead of constantly searching for the latest collaboration technology and practices to help solve a very difficult problem, the software development industry routinely settles for decades old techniques. The languages and services that we use maybe new and up to date but the organizational tools and procedures we follow rarely are.

Below are examples of categories where it’s unreasonably routinely accepted that older ways will not impact the project.

Software architecture and team organization

An architecture where each pair of developers has their own service to work on is very different from a monolith. The more self-contained a team is the faster they will be able to proceed, for instance protected by well defined APIs. Unfortunately some agile thinking is more concerned with business level constructs than whether or not the software is untangled at a technology level.

If for instance you have a platform team and features teams how much less agile are you right away, by design? The platform and feature teams end up joined at the hip and unable to deliver anything on their own. Had Amazon organized that way then there would be no AWS - instead of services it would be a platform baked into the core of their applications.

Collaboration tools

Collaboration tools can also help sub-divide a problem. The easiest example of this is a tool like source control. Even if we are working in the same code base the ability to branch and merge can help separate development enough to make agility possible.

Used correctly an issue tracker is also an important tool for agile development. If I can be assigned some small issue that is independent of others than I can proceed with agility. Where there is still a lot of room for improvement is with larger projects that cannot be immediately subdivided into distinct issues.

The first take at solving that problem is to jam the square peg into the circle. Let’s guess ahead of time all stories involved in a project and then enter them into an issue tracker. No matter that strategy is executed, complex projects and issues trackers just don’t fit.

Before source control technology, developers could use meetings to avoid stomping on others code but it’s a poor substitute. Now to avoid wasting time in meetings, you need a collaboration tool where support for decisions about what to do next and how are built right into the tool.

Process

I heard someone joke recently that they couldn’t wait to get back to the office so they can use sticky notes again. It’s funny but it’s also not so funny. Software development methodologies are not like wine, whiskey or cheese that can be stored in barrels and get better with age.

This again comes down to whether or not you believe software development is an intrinsically hard problem. If you don’t think its a hard problem then the idea that we have a winning methodology that we can use for all time will appeal. If you accept that running software development is at least as difficult as say, running a sports team, then the sticky note joke is the equivalent of a basketball coach bragging he mostly ignores the three point line.