Software Development Tools I Won’t do without

I’ve been developing software for over 20 years now — since way back before Windows 95 was released, back when the internet was just starting to be something that the general public had heard about. That seems like a long time to me, but when we compare that to the time that other professions have been around — think of things like engineering or medicine — we are but babes in the woods. We have learned a lot in that time, and because it is such a young profession, we have had some pretty major changes in the way we do things. As an individual, I have had several key learning experiences where I decided that what I had learned was so important to my profession that I would no longer do things the old way. I’m currently working for Datical, a provider of Database Schema Change Management tools. I see the software the Datical provides as one of those big leaps — something that no professional software developer should go without any longer.

I think my first big leap was right after college, when I started having to work with other developers. When you are a solo developer, it might be fine to keep all the source code for your projects on a single machine, and just periodically make backups. But as soon as you start working with others, you start having conflicts — one developer will change a section of the code in one way to address one problem, while another developer will change the same section of code in another way to add some new feature. The industry developed source code control tools to manage this problem, and ever since I started using source code control, I will not work without it — even for my personal side projects where I am the only developer. I remember meeting someone just a few years ago at a conference who didn’t use source control at their company, and it was almost like meeting a doctor who didn’t wash their hands.

The next big leap for me was in how I built my software. In my early career, each developer would have their own way of compiling and packaging the source code into a product the end user could work with, and one developer’s environment could be vastly different from their teammate’s environments. The first step was standardizing on build tools like ‘make’, and then making sure that there was a machine that didn’t belong to any developer that performed “the nightly build.” That was a great leap forward, and after I discovered the benefits of the nightly build, I made sure to never work without it again. Any new team that I joined, I would quickly assume the role of ‘buildmaster’ and make sure that we had a consistent process in place. I do still occasionally hear of teams that do not do a nightly build, but I liken them to engineers that still use slide rules. It might work, but it isn’t a best practice.

Development teams got a huge boost when they started going from simple nightly builds to building and testing their software with every change committed to source control. “Continuous Integration” is yet another improvement that I simply will no longer work without. At about the same time that continuous integration was introduced to the world, the software development community also started experimenting with various sorts of ‘agile’ development processes. Between the technical practices espoused by the Extreme Programming community and the process improvements coming from things like Scrum, the way we developed software changed radically, and for the better. When I learned the benefits of test driven development — better design, plus a safety net that allowed me to make the changes demanded by my customers without fear — I stopped doing things “the old way”. I am not dogmatic about always writing tests before every change I make, but I start with a test far more often than not. I also hear that there are still teams that ship software to their users once a year or once a quarter, but I have seen so much benefit from doing releases every month or every two weeks that it would take some very strong reasons to get me to go back to the old way.

All of this leads me to one of my more recent “aha!” moments. I have worked on many projects in my career where the software had to work with a database. Nearly all software that we use today has a database involved somewhere. Your desktop accounting program, your online banking software and your favorite smartphone social media app all have one ore more databases somewhere. As the applications change, grow, add features, and fix bugs, the database has to change right along with it. And the software development community has gotten really good at making these changes, supported by all these innovations — source control, continuous integration, tests, agile processes. For many years, the database has been left out of that, for various reasons. But about six years ago, I worked on a project where the database was managed using a new tool called Liquibase. The developers and the DBAs worked together as a team, each making changes, supported by source control and tests. Things ran smoothly and we stopped worrying about deployments to production that had mis-matched database changes.

This is what Datical represents for me, and why I’ve chosen to work here. Bringing the database into the realm of modern software development practices. Making it so that the people writing and running the software that keeps their organizations going can spend time with their families rather than stressing over a manual deployment. Letting people do the cool and innovative parts of their jobs rather than working on the tedious parts. I simply can’t imagine working without it.