Process Is King

Tech Room

How a proper software development process helps you deal with unforeseen problems

Software development is often unpredictable. Changes in the infrastructure or libraries we depend on happen. Bugs come up. Milestones slip by. To be able to deal with all of those changes, we need a proper process in place that will help us deal with unforeseen problems and give us the confidence to upgrade any part of our system at any time.

Often, we only perceive dependencies on a library level as they are the ones we deal with daily. Not updating those means taking on technical debt. By setting up proper automated testing and continuous delivery where the system tells us when it’s ready, we can get to a point where upgrading any library is simple. But this workflow often doesn’t extend to more basic parts of the infrastructure, like the Operating System we use on our machines. We often take them for granted as their release cycles are slow and they are typically supported for a long time. But depending on that level of support, without a well-thought-out plan to update these parts, it just pushes the pain of dealing with it to a later point, where it becomes chronic and much more difficult to manage.

So even the best development process with automated testing and continuous delivery can’t help us if we don’t consider the whole system while building workflows.

Managing Large Changes

We’re currently in the process of upgrading the Ubuntu version we use on our servers. Those changes took quite a while to implement. It wasn’t just a technical challenge to provide the same consistent high-level of quality we expect at Codeship, but also to have a process that lets us slowly release those changes and find any problems we have before the general release.

We can now roll out different versions of our infrastructure based on different operating systems and decide on which of those to run our builds. This allows us to test the whole infrastructure much more thoroughly and ensures that we don’t negatively interrupt our customers’ deployments.

We had to dive deep into the process necessary to roll out these changes and decide on how our technology needs to support those processes. It’s often hard to decide early what these specific update paths are and how to deal with them in the future. But it’s critical to set up your team and development to see change as the natural order. We fully stand behind this and it’s something that we implement across our company and technology. We need to Build for Change.

While you might not need the technology or the process to replace every part of your infrastructure from the beginning, you need to be aware of the dependencies you build and how those might affect you in the future.

Conclusions

In software projects, we often build up dependencies that aren’t visible on first sight, but painful once we need to deal with them. So deal with them early and often, even if it’s just as an experiment on the side that isn’t intended to go into production. At least you’ll have the data and experience to work with, and a process to deal with that changes, once it becomes inevitable.

You will have to handle unforeseen changes, upgrades to your dependencies and general problems in your infrastructure. Sometimes those might turn out as minor or sometimes they grow while investigating them, similar to what happened with our Trusty upgrade.

If you fear those changes and ignore them today, they will come back even stronger tomorrow. A minor change, a small process improvement or a minimal technology upgrade becomes an unbeatable beast that will suck up your time, energy and productivity.

Prepare your team, your process and your technology for change. This will allow you to face it without any fear. Fear is what holds us back, fear is what decreases our performance and innovation. By preparing and reducing this fear, we can build products that are truly innovative and truly loved by our users.

Did you have to make changes you were afraid of? How did you handle them? Let us know in the comments.

Subscribe via Email

Be sure to join 13,643 subscribers of our newsletter to receive updates on software development best practices, Continuous Delivery and tips and tricks to start shipping your product faster.

Join the Discussion

Leave us some comments on what you think about this topic or if you like to add something.

  • david hite

    very good information. Change is good

  • Zelda

    Best way to manage difficult development is to use an automatic code generator. Draw the program with mouse and convert from bitmap into software.

    • https://www.codeship.io/ Florian Motlik @codeship

      I’ve never had any success with code generation or visual programming, but if you’ve had success with it would be interesting to read more.

  • Pingback: This Week’s Best in Change Management and Innovation

  • Dan

    Change I was afraid of… Legacy system, 7 years old at the time. Needed to be moved off windows servers. Case sensitivity was the biggest issue, thing that scared me the most was not a single automated test. Desired to move to Linux, and tried using a case insensitive file system, ran into all sorts of issues. End result was a compromise on OSx servers. They are case agnostic, and it worked best. The changes required where minimal and we got the legacy system up and running on the new platform. We’re now undergoing replacing the system all together, testing is a major focus this time around, along with “Build for Change”. We’re using codeship and three months in we are very happy with where codeship has gotten us! Keep up the great work, and the helpful blog posts.