• Posted by Intent Media 21 Jul
  • 0 Comments

Growing Software

Let’s stop thinking about software the same way that we think about building other products. Let’s start thinking about software in terms of growing something.

I was recently reading The Mythical Man-Month. I’ve been trying to read software engineering classics to reflect on the evolution of software engineering. In 1975, Brooks was talking about incremental development in terms of growing software instead of in terms of building it.

I thought that this was a very interesting way of looking at software development. There is a lot of buzz right now around fast incremental development and fast iteration, but people in the tech industry still speak in terms of building software. I think that when you think about growing software instead of building it, it has a positive impact on your daily tasks. It helps you plan your work differently and changes your attitude towards your work and co-workers.

Building vs. Growing

Building something implies that you have a clear plan, a path to success. If there is a plan, by definition, decisions have been made ahead of time. Most of the requirements are set in stone. Only the small details are yet to be ironed out. The construction worker might use a hammer and another worker a nailgun, but both workers will be building a wall at a specific place according to specific requirements. The core task has been determined; all that remains is merely implementation. When you have to build a physical structure, it’s hard to come back and keep adding to it.  It’s hard to accept that a wall has to be moved, that someone built it the wrong way.

Growing a thing is different. When you think of growing software, you can think of software as being organic.  It grows and evolves.  It changes with the season, the environment, the specifications, and the people. Growing means that after a while, the software will have rotted. You must be ready for this software to be refactored, changed or replaced. You can now think of the path to success consisting more of milestones than of releases or published artifacts.

Legacy Code

When you think of software as growing organically, you stop blaming the previous developers of the software for making bad choices.  You start thinking about why it was implemented a certain way originally and how can you make it better. It’s not always wise to dump everything and rewrite the application completely.  Sometimes you should try to understand the previous decisions before attempting anything too drastic.

When I think about software as something that grows, that perspective allows me to have a much more positive attitude when I approach a new piece of code.  It also allows me to have a much more positive attitude towards my colleagues when we’re pairing or reviewing each other’s code.

Software is tightly coupled to the people that write it.  People evolve, therefore software evolves too. Best practices also change, technology choices will be different as new tools and techniques are available. There are many different appropriate choices out there but people naturally pick tools from the toolbox of things they already know. A system might have been implemented in Java EE. That technology might not have been the only possible choice, but it was appropriate for the team at the time. You also have to keep in mind that it’s hard to keep track of all the changes and new tools that are released everyday, publicly or even internally.

Before coming to Intent Media, I have seen many developers curse old code.   Sometimes developers think that they are better programmers than the original implementers of an application.  One year later, those developers realize that their refactor was also bad.

Beyond the big changes, there are incremental changes, bug fixes, and new team members. New requirements come in from the product manager that are hard to implement in the current system.  It’s possible to ship the feature, but it has consequences on the structure of the code. Then you come back a few months later and curse at that feature that grew out of proportion, didn’t scale, or caused errors in production. Then, you were the actual implementer of that piece of code.

Conclusion

Working from the perspective of growing software, you’ll stop being afraid of changes. You’ll make new mistakes instead of old ones. Software grows, rots, and evolves, the same as people, companies, and anything else organic does. Do yourself a favor: accept it, embrace it.  Find a company that embraces organic growth as much as you do, and you’ll be a happy engineer.


Phil Rene is a data engineer at Intent Media. On the weekend, he is usually playing hockey, fishing in some remote location or enjoying good food from a farm-to-table restaurant. You can find him on Twitter and on Github.

Post Comments 0