 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
Enterprises are under constant pressure to increase developer velocity. In competitive markets, these teams need to get code written and have new features built, tested and deployed at a regular rate to keep customers happy and coming back for more. However, despite this existential need to maintain speed, unintended consequences of tool selection and organizational architecture hamper some teams, making it harder for developers to get code out the door.
These mistakes aren’t just going to lead to delayed product releases; they can also have unexpected human costs. Why? Because many developers would rather quit than work for months on end without getting to see the fruits of their labor. I once turned down a role working on cool technology in a neat environment because the manager at one point sighed and told me, “We haven’t released any code to production in six months.” In an industry infamously defined by “moving fast and breaking things,” who is going to want to work on a product where their efforts will have no tangible impact for half a year or more?
While there are many factors that affect developer velocity, the current dev environment is largely dealing with three major enemies. Here’s what they are and how teams can overcome them to get back on track.
This issue was highlighted in a recent tweet from Joe Magerramov, where he argued that the biggest impediment to feature velocity is architectural, particularly when “launching any feature requires multiple teams to contribute, especially if those teams are far apart organizationally.” While I might push back on whether that’s the biggest or only impediment, he has a point. Complex developer organizations should be evaluated and streamlined to ensure that a tangled org chart isn’t leading to delayed releases. The fastest route will always be a straight line.
I believe we should be testing in prod to increase velocity, but we should develop effective rollback tools to enable us to test in prod more often. By designing our systems to revert back to previous versions when certain triggers are met, we can ensure that our developers are able to get a good night’s sleep, even when they’ve deployed new code that they’re not 100% sure of.
In the long forgotten past, every developer could run their whole web front end on their PC, meaning that any changes they made to the code could be tested locally with 99% accuracy to how it would work in production. But with the advent of serverless, we’ve now spent years working in environments where this is nearly impossible. When this shift took place, we should have built the tools necessary for local emulation of new environments. Until we catch up and create these solutions, developer velocity will suffer as a result.
Here’s the thing about increasing developer velocity: It doesn’t have to be all or nothing. We’re not necessarily talking about a tooling change or an organizational overhaul. Instead, it’s a change in mindset to accept that releasing imperfect code can be the norm rather than the exception, acknowledging that a small increase in errors will lead to outsize increases in velocity and more features being delivered to happy customers. That can be a minor change. Maybe your postmortems will become frequent, fun and non-accusatory!
Take a second and look around at your dev teams. What’s slowing you down? If you increase the rate at which you release slightly imperfect code by just a little bit, will your team move a lot faster?
