The virtuous cycle of software change

In the past, programmers built software that we considered good. Today programmers build software that we consider good. Under the hood though, they are built differently even when the requirements are identical. If someone built a new system with the technologies, tools, and designs of 10 years ago, it would be looked at as odd, if not wrong, even if it worked perfectly for the needs of the system. We’ve adopted a dogmatic love of the new and it drives the obsolescence of software professionals.

We build new tools to deal with the flaws of the old, but just throw away the old stuff without considering the reasons that the old tools was considered good to start with. Maybe it’s because there are so many new tools that by the time someone has built something big enough to expose the problems with an old tool, there is already a set of new tools waiting to fix that problem; like SOA to microservices. There is no obligation to even contemplate whether the old tool continues to have value. There are also plenty of examples of technologies that ran into problems in public and developed a reputation (deserved or not) because of it, e.g., the usage of rails at Twitter. Obviously people are still using older tools, but the tools’ reputations haven’t really recovered from the public hit and adoption therefore slows.

The focus on newer tools and technologies, and more specifically tools and technologies you aren’t using at work already, feeds on itself, causing people to want get new technologies to keep up to date. Some businesses have reacted to this technological churn by trying to slow this sort of resume-driven development by locking down new technology introduction and upgrades through a change management process. This means that if you, as a programmer, aren’t taking care to maintain your own continuing professional education, you can get left behind. This probably won’t impact your ability to do or keep your current job, but it could impact your ability to get the next job you really want. If you are only getting experience on one stack or set of tools and not bringing in outside ideas then you will silo yourself. This is the same issue that Michael O. Church wrote about – that most organizations wouldn’t want to hire the people who had 4 years of experience of the calibre most people in their organization get, they want something new and shiny.

If the experience you get at work isn’t good enough to get you the same quality of job that means you need to go get that experience other ways. The obvious answer is some sort of open source project. There are a couple of other ways – making an app, moonlighting, a toy program, or just some sort of hobby project. This personal drive by passionate programmers intent on expanding their skills has caused an explosion of these sorts of projects, which has great consequences for the world. As software developers there are a plethora of tools and libraries to help us accomplish what we want to do (and feeding back into the cycle). Projects like the Humanitarian Toolbox (community-created software for disaster response), which nobody would have paid for, help those in need, and a great place to expand your technical horizons.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s