Producing Software Quickly and Consistently
This is a first draft of my current thoughts on what a nice environment for software creation might look like and some reasoning behind it. This is by no means a definitive guide or a set of rules to succeed, it’s simply my current understanding which I know needs to be continually improved. My hope for these articles is to update them as appropriate once an area of improvement is identified and then again once a solution or set of solutions seem to be reasonable. My main thought behind software creation and maintenance is that software is always changing and will continue to change. With that solutions and practices should evolve as well, that’s what I would like to happen with these articles. With that in mind creating an environment where change can happen quickly and consistently is key and should be encouraged.
The topics I would like to focus on in the articles are: developer tooling, developer workflow, everything as code, Continuous Integration (CI), Continuous Delivery (CD), and feature control/testing/validation. I would encourage people to thinks about these things less as the tools they have used in the past on more a higher level concepts that can be represented through different tools. This makes the ideas more flexible to meet the different needs of the people or organizations trying to implement them. It can also help a project grow more smoothly as an outcome can be adapted over time along with new and existing tooling if needed.
The main thing to consider and the core of all of this is how do you make it easier and faster for a developer to get their changes in front of customers so they can get feedback. While also having the ability to continually fix bugs and add new features. Finding this balance and around speed and quality assurance is key and should be thought of along a spectrum that makes sense for your business and your customers.
This can be broken down many ways but I find the major categories to be:
Developer Tooling: This includes the tools they use from computers all the way to code completion and everything else. Anything that could take the load off them while still providing the control to do their job well.
Developer Workflow: How a developer actually takes a task and turns that into production code. What roadblocks are along the way? How much really needs to be done manually and what can be automated? What are your goals as an organization with your developer workflow and do these goals currently line up with that you make developers do?
Everything as Code (Make Everything Explicit): This can have many names, infrastructure as code and others but the same basic idea is you want to make the current state of everything you control visible and explicit to everyone who will need to work on it. That way changes can be made or reversed and you can consistently reproduce your environments. This should provide a lot more peace of mind to everyone on the team because you don’t have to worry about settings in dashboards or missing toggles if a ui has changed since the last time a resource was created.
Continuous Integration: This should be considered part of a developers workflow as passing this should be the last step to getting code ready for deployment. As with all the pieces there should be thought put into how making continuous integration faster and more comprehensive can actually improve you organizations speed. While it may see counter intuitive to say a more comprehensive CI could both be faster and more efficient. This can actually be achieved as we will discuss in the article that discusses CI.
Continuous Delivery: There should be an important distinction made here, this does not mean you always ship new features or have to ship new features before they are ready. This should mean that you are always deploying on a regular basis or when there are changes. Whichever fits your organizations needs. The release of features should be controlled by features flags or another separate system. This way features aren’t tied to deployments and deployments aren’t tied to features. Allowing organizations much more freedom in when they would like to deploy and then when they would like to actually enable a feature. The main goal for continuous deployment is to ensure that new changes are always deployed as soon as possible so any changes can be validated for stability and reliability. This should ensure that a new change doesn’t cause more errors, crashes, use more memory or cpu than anticipated. Continuous delivery should focus on the more technical side of ensuring that the code was deployed correctly and is working as expected. Turning features on and off should be controlled by a different system that we will discuss next.
Feature Control/Testing/Validation: The main goal of this system should be to remove the act of enabling or disabling a feature by having to deploy or rollback. This way features can be turned on or off separately making sure regressions aren’t introduced again on a rollback or that a problem with one features doesn’t interrupt the progress other features are making. It also provides each team with more autonomy and allows them to move faster or slower depending on their own progress. This system can also be used to experiment with features as well. Helping to provide you team with information about how a new feature has impacted the user or if users are even using a new feature. This can help guide everyone in an organization to focus on the most high impact or valuable features for users while maybe moving on from ideas that have proven to have little or possibly negative impact on users. This gives the power and control back to teams because not only are they continuously testing and trying new things to improve but during problems these features can also be used to degrade services gracefully and avoid outages. By say turning off expensive non core features during large spikes in traffic leaving more resources for core business features to run under heavy load. Or to turn off features that have broken or degraded because they rely on a third party who is currently having problems. Instead of showing a broken feature to your customers you can simply turn it off while it is not working. This can also really help relive some of the stressful situations that happen when people are on call. No one wants to try and rollback a service by themselves at 2 am when they aren’t even really awake. But turning off a broken feature with a simple change or in a UI can really help to reduce stress and buy time as the root cause is investigated.
Hopefully this provides an overview of the different areas in the process and how individually they are useful but all together they can create a far better development experience for everyone involved from developers, managers, and users. Each topic will be discussed in more detail in their own posts.
Below I have added some links to different sights and resources that I have found very useful myself and go into subjects in much more depth than I do here. Martin Fowler covers all of these topics on his site in their own articles.
