If software assets are a key part of how you deliver value to your customers, you want to move fast. The faster you iterate and experiment, the faster you can deliver more and more value to your customers and, ultimately, your shareholders. There are two ways to think about speed to market:
- Whatever you’re doing right now, do it as fast as possible. This is war, and we might not survive to see tomorrow.
- We should move with purpose and urgency, but not at the expense of speed tomorrow.
When we think about delivering software fast, we idolize teams that have a reputation for being nimble. Most of us have never been a part of one of those legendary teams, and even fewer of us were a part of them early on. We have a perception of something like Usain Bolt in the Olympics absolutely demolishing the competition with what seems like no effort. What we don’t see is where they started. We don’t see the pain they went through and the dedication to a process over years and years in order to dominate with poise.
The point is that moving fast requires investment. To be clear: An investment always defers gratification in favor of outsized future returns. It never feels good when it’s happening. But it always feels good when it’s paying off. Investment requires discipline to be effective. Here is a list of the investments that I’ve seen offer the best returns in software development.
Vision
Create a clear understanding of where we’re going. This goes for any leader. Think big. Think long-term — a point on the horizon that might seem almost unreachable but totally inspirational. If the team has internalized a clear, cohesive understanding of what we’re shooting for, everyone will make better decisions. Executive leadership will be able to make more aligned strategic decisions. Product leaders can set the right goals. Developers can make technical design decisions with a clear understanding of trade-offs. The brand will resonate better with customers. Without a clear vision, everything else will be a struggle.
Process
Process is the air we breathe. It’s the rhythm of life. When we think about process, we shouldn’t think of it as a rigid, robotic way of moving through tasks and deflecting out-of-band requests. Rather, think of your process as a framework for making decisions easy and work manageable. When done correctly, the process is almost unnoticeable, and our focus is on the most valuable output: well-executed product. The process with which I have seen the most success is outlined (for the most-part) in a previous post.
Whatever you do, I’d recommend aligning very strongly on a proven, documented process and invest in good supporting tools. Resist the urge to make up your own process. Your company is not special. Your customers, while awesome, are not unique. Don’t make up your own version of [process name here].
[Good] Tests
Of all the items in this list, this one is the hardest pill to swallow for the majority of teams. It’s easy to understand why. I’m pretty good at writing good code quickly and making sure it works on my machine. “Ship it!”, right? Why spend twice as much time writing tests as you do the code that they’re testing? There are a lot of reasons. Here are a few:
- When you iterate on this code (and our goal is to iterate fast), you want to have confidence that you didn’t inadvertently break something in the process. Early on in the project you’ll think you can get away without this concern — and you’re probably right. But there will be a point down the road that this will definitely slow you down WAY more than the time it would have taken to write the tests in the first place.
- Tests are built-in documentation. When well-written they tell us exactly what the code in question is supposed to do. This will be essential to all the developers that come after the original author.
- Upgrades are much less painful. Almost every software product today has underlying dependencies that are constantly being updated to fix bugs and security holes. Upgrade early and upgrade often. If you have tests, you can proceed with relative confidence.
- Deployments are a yawn when you know you can trust your code. Remember the image of confidently crossing the finish line of a sprint as if it was nothing? This is similar. You’re doing things right when deployments are a non-event.
Infrastructure as Code
For any software served from the Internet, you need a place to host the deployment artifacts and all the things they depend on (databases, CDN, etc.) Chances are that you use some big-name cloud infrastructure provider. You can point-and-click in a web page to create your infrastructure. This will not set you up for long-term success. As software evolves and scales, the underlying infrastructure changes to meet the software’s needs. You will be much less frustrated and incur much less risk by keeping your infrastructure as code that allows you to make small tweaks or sweeping changes with minimal breath-holding. I prefer Terraform/OpenTofu, but you do you. As with process, don’t try to roll your own.
Continuous Deployment
I hold a very strong opinion that all deployable software should be deployed as often as possible. For every project that I have authority over this means every merge into our main branch deploys to all environments immediately. Why? Because deploying the smallest change incurs the smallest risk.
Implicit in continuous deployment are a couple of prerequisites:
- Trustworthy tests (covered above) that run in a reasonable amount of time
- Feature flags that allow you decouple deployments from feature releases
Invest time into getting your build+deployment pipeline set up neatly. Inevitably it takes way more time and trial-and-error than you want. But once it’s set, you’re set to crank out features in the software your customers use. The specific tool isn’t necessarily important, but I’d recommend going with a name brand. I would also recommend adding gates to your PR and build pipeline to keep code quality up like linters, static analysis, test coverage, etc.
If you’re interested in learning more about my opinions in this area, I did an interview with LaunchDarkly on the subject. I also wrote this post a while back that has aged decently.
Documentation
Documentation is so unsexy…to me, at least. But documentation can save incalculable developer-hours. Write down design decisions made along the way — for team alignment and posterity. It doesn’t need to be formal. Just add it to the README. I can’t tell you how many code bases I’ve looked at and thought, “Why would anyone do this?” and found no answers anywhere or with anyone on the team. It’s not that the decisions were bad. They were just made with different information under different circumstances. How fast can I iterate on software that I have to reverse engineer in order to understand how to move forward?
Instrumentation
Informed decision…The term literally has a form of the word “information” in it. Business decisions require data. In this context, we need to be able to understand if our assumptions are correct as we iterate on our product. In order to collect data, we need to instrument our digital assets to gather user behavior data as well as application performance data. This could be as rudimentary as Google Analytics. Hopefully you’re looking for a little more detail and get into things like A/B tests, APM, DORA, error alerting, etc. Even if you don’t use Segment (which is a great product), you might peruse their list of integrations to get an understanding of the possibilities instrumentation can open up. Regardless, it’s much easier to establish a pattern of instrumentation early than to take on the tedium of retrofitting.
Eyes on the Prize
If we invest wisely, we will reap the rewards — theoretically forever. If we see these things as expenses, we will wallow in debt, accruing interest, until we decide to pay it down, hopefully before it’s too late. Honestly, the investment is relatively small when you take it on as the top priority when beginning a project. Literally somewhere around 2–4 weeks at the beginning of a project can put you years ahead of where you would be otherwise within 12 months. And you’ll only be gaining moment as you go.
