Finishing Fast

Have you worked in a team where there is a software developer that seems to implement working code significantly faster than others much of the time?

Perhaps you have been that programmer. If not, perhaps you would like to be that programmer?

I’ve been that software developer many times, and not by working evenings and weekends.

Fast or good?

Deliver as quickly as good allows. Always. It’s not a choice between fast or good. Always go for both.

And working readable code is good.

With this standard in mind, build and encourage the habit of prioritizing delivery of stake-holder visible functionality and critical infrastructure plumbing over potentially premature refactoring.

So never improve existing code?

Should working readable code ever be refactored to improve the readability, maintainability, or performance? Sometimes yes and sometimes no.

Always do what’s most valuable at that moment. Choose.

Better Performance

Working readable code means the code already performs to stake-holder requirements; including the performance needs for that iteration. Do you have something more important to do right now?

Better Maintainability

Most skilled developers can always find additional refinements to make to their already working code to make it more elegant and standards compliant. Of course, tinkering with working code always injects the very real risk of breakage. Is this tweaking the most important task right now?

Always do what’s most important to do

Choose to do what adds the most value at the right moment. And to be fast while delivering high-quality, embrace the idea that the right moment might best be later and maybe never. (Check out the idea of "premature optimization" for more insight into the very real benefits of embracing delayed refactoring.)

Your best speed

Of course, with more practice and experience we all become more capable of producing quality working code more quickly. The key for us is to work at our best speed whatever that is right now.

Always hold yourself to what you consider the minimum standard of readability and standards compliance as you work at your fastest pace.

The most highly skilled developers will rapidly produce high quality code that meets and generally exceeds a team’s reasonable standards of syntax and style compliance. With time and practice all developers improve in skill and the velocity of delivering good working code improves along with that skill growth.

Do your team’s minimum code standards encourage high-speed value delivery or encourage something else?

What are you measuring?

Are your tools and procedures directly measuring how quickly high-quality functionality and critical infrastructure is being delivered? Are these measures rewarding that or something else?

Are your measures encouraging delivery of what’s most important at just the right time? And emphasizing delivery like FAST matters?

Are your measurements and standards encouraging a mindset of sustainable urgency?

Cultivate the urge to finish

To sustainably deliver high quality at our quickest pace it helps to become uncomfortable with diverting our attention to anything that is less important in that moment. And we need to cultivate an appetite for finishing fast.

Finishing makes us available for the next important thing.

And delivering just what’s important at our fastest pace is sometimes all we need to be the quickest software developer on the team.

What would a team of faster finishers look like? Can entire teams perform above the average?

Yes.