Faster Software Development

If you’re building software and you’ve got a decision to make about how you run your organization, or what technology you might want to use, the very first question you should ask is: Will it make us faster while not sacrificing essential quality?

Every Decision Matters

Over the past eight months I’ve had the pleasure of working inside some really great companies who are building some very interesting products. When I get asked to review or help out, I always start with a high level overview of how they’re managing their day to day work.

• Have they documented how to onboard a new developer to the product?
• Where is the source code repository?
• What task / project management tools are you using?
• How does the team communicate?
• How do they divide up work?
• Do they have a continuous integration pipeline?
• Are they using continuous delivery?
• How are they testing what they’re building?

The answers to these questions tell me almost everything I need to know about the organizational culture. It also has the side benefit of exposing the compounding effect of small decisions.

For example, if a team decides to host their own source code repository, it’s not a good or bad decision in isolation. However, they’ve now introduced an administrative burden for adding new users, integrating to other systems, and so on that wouldn’t exist if they were on Github.  So now if they want to publish build reports to Slack, or integrate with Travis or CircleCI, someone has to do that work manually and figure it out.  Meanwhile, their competition just clicked a few buttons and went back to working on the product.

If they’ve chosen not to have adequate test coverage or integration / delivery pipelines because “we need to go fast right now”, I know they’re not taking into account all of the hidden costs of manually pushing builds or fixing bugs that should be easily discovered through test automation. Every decision matters.

Cascading Speed Bumps

Generally what I observe is that bad decisions lead to more bad decisions. If a team is too lazy to do the work to make it easy for the next team member to be productive inside of an hour, they’re probably too lazy to worry about picking the best possible source code host, or adequately covering the code in tests. The result is that teams get slower and slower due to unnecessary complexity and mistakes.  Humans are terrible at keeping track of details.

The opposite is also true. If a team makes solid decisions in the interest of more productivity for everyone all the time, the pace at which product development moves can be staggering. These are the teams others sit back and wonder “How are they doing all of that so fast?”

Growing a Faster Development Culture

If you’re running a company that’s building a software product and you’re not satisfied with the pace, it’s time to take a step back and start asking the basic questions, some of which I’ve outlined above. For every decision, ask the question: “Will this make us faster now and / or faster later?”

If the answer is no, ditch that part of your process and culture and start over.

We’re about to enter a new age of speed in building applications powered by powerful new automation capabilities.

Are you ready, and is your team ready?