There is no getting around it, customised software development requires a significant investment. High quality results do not come cheaply, so it is important to make sure that everything possible is done to achieve the best return. Keeping developers moving along at a crisp pace on the core task is vital, and poor infrastructure can add a huge overhead to development. To ensure this problem doesn’t occur, there are a number of areas that need to be running smoothly:
Are changes made by developers always tested at the first possible chance?
Can developers make changes confident that they won’t break production releases?
Are changes propagated smoothly and automatically through the system?
Do you know the code coverage of your test system?
Is it simple to set up a new development environment?
Are developers able to make their own choices about customising their development environment?
Most of this boils down to one thing - automation. Automated testing, automated builds, automated releases. Over the course of many decades of combined software development experience, we’ve come to the conclusion time spent automating any part of the developer process is always a good investment. As projects grow in size this process gets harder to implement, both due to the higher initial hurdle and the difficulty in creating a system which satisfies the opinions of all involved developers. As such, wherever possible, this should be done as early on in the development process as possible. These systems don’t have to be complex - having a script which runs every night, builds all the software and uploads the output it to a file repository instantly gives developers some level of confidence. It is also much simpler to create a good solution incrementally than to jump in the deep end. The ultimate goal being that developers can focus purely on quality software development, and not have to deal with issues such as building and releasing.
For many people, this won’t come as much of a surprise. Good software practices have been well known for decades. Back in 2000, Joel Spolsky wrote very succinctly on this. One of the key differences now is that modern cloud service offerings mean that the actual overhead to software companies for this kind of automation is now lower than ever. Don’t have time or staff to set up secure software version control repositories from which an automated build system can grow? No problem, GitHub, GitLab, or any number of other vendors are happy to provide. Need a dedicated build machine? Have a preconfigured VM set up in mere seconds. Not only are these offerings cheap and easy, they are generally of excellent quality with very good security policies. Setting up quality internal infrastructure is not a one off cost, it requires constant maintenance, patching, security review. Cloud services remove the bulk of this responsibility.
As a final anecdote on these points, we’ve found that developers are generally more interested in writing code than they are in dealing with infrastructure. So not only do you get better results through automation, but people are happier about their work as well.