Magic in Software Development

There are two times in my life that software development has felt like magic.

The first was in high school. It was 1999. A friend of mine had created a computer program that showed different images when you clicked on the related buttons. At the time, I remember thinking, "Wow, you made your own computer program? From nothing?"

As a 13 year old kid, I had used computers before, but the idea of creating your own program blew my mind. It seemed like magic. It was one of the main points in my past that led me to a career in software.

The second time was while I was working on a project a few years ago at a client.

I was a business analyst on an Agile development team, building a financial modelling tool from scratch. I worked closely with different people in the team, including the testers. The role of the testers at the time was to manually test each feature as it was built to ensure it did what we wanted to do and no issues were found.

The developers in the team began working on something they called "continuous integration and continuous deployment". I knew a little about it, but as a business analyst, I had no experience with it. The developers gave updates to the team about it during stand-ups occasionally or when a milestone was reached.

A few months later, they mentioned the setup was finished. They explained to me, and the others in the team what they had done.

They had set up continuous deployment, continuous integration, and the basics of automated testing on our project.

This meant that every time a developer made changes to the code and checked it in to the central source control:

• A separate set of code would run to ensure all of functions they wrote worked as expected (aka the unit tests).
• Another set of code would run to ensure that different processes would work correctly (aka integration or component tests), such as logging in or creating a new record.
• If any of these tests failed, the team would be notified immediately.
• A separate tool would automatically detect how much of the developer's code was covered by these tests, so gaps could be found (aka code coverage)
• The tool would also check for the quality of the code, improving the way the team wrote code.

It also meant, for the rest of the team:

• We could deploy our code from the source control to the test environment at any time we wanted
• We could start a deployment rather than ask a developer to do it

What Did This Mean?

After they explained it to me, I understood the impact of what they had done.

The work they had done meant that:

• The source code was being checked for possible bugs each time it was updated, and being fixed as they are found, meaning the code was always error-free (as long as a test was made for it)
• The testers did not have to test the entire system each time a release was made, as this was already done. They gained an incredible amount of time which they spent doing exploratory testing and other tasks.
• Deployment happened automatically, without any human intervention.
• Work was getting completed quicker, because the testers could start a deployment when they were ready, rather than wait for a developer.
• Maintenance of the software was much easier, as bugs were found earlier and testing was automated.
• The business was getting more value, because the software had much less bugs and features were being deployed faster.

Coming from a background of working on projects with manual testing, lots of bugs that were uncovered, and slow testing and deployment processes, this blew my mind.

The software could be tested for any bugs each time a change was made, prepared for a deployment, and at any time anyone in the team can click a button which deploys the code automatically to a specified environment.

It was magic.

What's Happened Since

Since then, I've read a book on the subject (Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation) and many blog posts.

I've also implemented it in a side project I'm working on. This means whenever I check in some code, it runs a series of tests, generates a code coverage report, and deploys it to the server (using Travis CI, Coveralls, Scrutinizer, and Heroku). No more manual testing and deployment.

This has allowed me to understand more about the process.

It's also relevant to me know because the current project team I'm working with is in the process of setting this up. I'm looking forward to the day it's set up and seeing the benefits of it to the development team and the wider project team.

If you're working on a project team developing software, and they haven't set up continuous integration and deployment, I recommend starting.

Speak to the team to get their thoughts on it, understand their experience, and work out what the next steps are.