Writing quality code under time pressure?

These hackathon teams prove it can be done

Last weekend 63 teams gathered in the old Sugar Factory in the Dutch city of Groningen for the world’s largest Blockchain hackathon. Here is what we learned from these teams about writing high-quality code under time pressure.

Quality under pressure?

Anyone can code. There are no formal entry criteria. An inquisitive mind and a laptop is all you need.

But writing quality code can be hard. Each programming problem can be solved in many different ways, some clean and straightforward, many muddled and messy. To turn an initial working solution into an understandable, adaptable, testable, reusable nugget of code takes time and dedication.

But most programming happens under time pressure. Pressure to ship a feature, pressure to squash a bug. Users, clients, testers, product owners, and team mates are waiting for you to close your ticket and move on.

And with the clock ticking, most teams find themselves compromising on quality.

Compromising on quality

When compromising on quality is a conscious decision, we may call it “technical debt”: taking out a loan to be paid back through future refactorings.

Conscious or not, when we compromise on code quality, we rarely come back at a later stage to mend our ways. Rather, we double down. Struggling to understand existing code, we add new code that is even messier. The “broken-window syndrome” also applies to software.

And so begins a vicious cycle. Once quality decreases beyond a tipping point, it becomes infeasible to recover. No time, no budget, no support for a prolonged feature-freeze to allow complex, multi-sprint refactorings.

“Yes. I hold that once we slack on quality, we’ll never get it all the way back. We’ll be slower forever by some amount.” — Ron Jeffries

In the end, coding (too) fast is self-defeating. Lower quality code is harder to maintain and extend. Bugs take longer to find and solve, and often re-appear. Adding or changing a feature becomes difficult and error-prone.

Can we maintain speed AND quality?

Yes. There is a way to code fast without compromising quality. In fact, the only way to code at a sustainable speed is by not compromising on quality. Here are the essential ingredients for doing just that:

1. A definition of done for code quality — a set of clear guidelines that the team embraces to decide when code is of high enough quality to merge and move on. We defined 10 such guidelines in the O’Reilly book Building Maintainable Software.
2. An immediate feedback mechanism that determines whether a piece of code conforms to the guidelines. And provides us with actionable information on how to quickly regain compliance. We created such a feedback mechanism as a GitHub integration called Better Code Hub.

With these elements in place, quality deficits can be flagged as they are introduced and nipped in the bud. A tiny investment in quality at each commit that pays back 100-fold in all the commits that come after. A drip of oil to keep the machine spinning without friction.

Quality code at the world’s largest Blockchain hackathon

When it comes to coding, the ultimate pressure cooker is a hackathon. Build a working piece of software within a day or two. You are on the clock. You are inventing as you go. Ideas are raw, teams just met, solutions are still unexplored.

There is a huge temptation to just slap some code together without ever looking back.

So, what better opportunity than the world’s largest Blockchain hackathon, to find out whether quality code can be produced under the pressure of time. Last weekend 63 teams gathered in the old Sugar Factory in the Dutch city of Groningen for the Blockchaingers Hackathon 2018. Coding started at noon on Friday and ended 48 hours later at noon on Sunday. A competition among teams, a race against the clock, an intense struggle of each developer with the complexities of mind and machine.

“When coding for the future, write future-proof code”

Supporting quality

Here is what we did to support the teams in producing high-quality code:

• Before the Hackathon started, we gave the teams a 1-hour Masterclass on code quality, explaining the relevance, introducing basic concepts, presenting the 10 guidelines for writing future-proof code from Building Maintainable Software, and showing them how to use Better Code Hub to keep an eye on compliance with those guidelines.

Each push and pull request is checked by Better Code Hub against the 10 guidelines for writing future-proof code from Building Maintainable Software. Feedback is provided in the GitHub conversation flow. When quality has decreased, click-through to detailed feedback per guidelines for concrete pointers on how to improve.

• During the Hackathon, Better Code Hub provided feedback about the impact on the guidelines each time code was changed. In all, such feedback was given on about 4000 contributions. The current scores of all teams were displayed on a huge screen for all to see. Also, code-quality Jedis were present to assist the teams in person or through Slack with activating Better Code Hub, asking questions about its usage, and sparring on refactorings, design patterns, testing approaches, or any other topic related to software quality.

The current code quality scores for all teams were displayed as GitHub badges on a central scoreboard for all to see.

Quality results

So now the “Stop Coding!” alert has sounded, the winners have been awarded, the Hackathon is over, and the dust has settled. What was achieved in terms of code quality?

• 19 out of 63 teams delivered a prototype that scored 10 out of 10. Wow! These teams prove that delivering high-quality code under intense time-pressure is possible!

19 out of 63 teams (30%) delivered a prototype that scored 10 out of 10, proving that writing high-quality code under time pressure is possible.

• During the hackathon, many teams used the feedback from Better Code Hub, not only to sustain their initial level of quality, but to make quality improvements.

During the 48-hour hackathon, many teams were able to raise their scores above their initial level.

• Delivering quality code is fun and rewarding. Look at how these teams show off their scores on their Impact canvasses!

Some of the Impact Canvases showing Better Code Hub scores.

Lessons

So here are a couple of important lessons that I learned from supporting the Blockchaingers Hackathon with Better Code Hub.

• Code quality control does not need to be disruptive — The feedback that Better Code Hub gives to developers is concise and to the point, and localised close at hand in the GitHub conversation flow. When a green checkmark appears, feel free to move on to your next contribution. When a red cross appears, dive in to get clear pointers on what to improve before moving on.
• Code quality control does not slow you down, but speeds you up — By acting immediately on the piece-meal feedback that Better Code Hub provides, rather than waiting for running into bigger problems later, minimal effort is spent on keeping the code base clean. This effort pays back on every subsequent contribution.
• _Setting and achieving a clear quality goal is rewarding and stimulating —_When the goal is achievable, and progress is observable by all, the team gets loads of positive energy out of quality control.
• High-quality code provides a solid basis for post-hackathon acceleration — While some hackathon teams disband and abandon their prototypes, many use the hackathon as a spring-board for a new venture with a new product. High-quality code provides a head start in the right direction.

Accelerate towards funding

Based on code quality scores as well as the overall design quality of the prototypes, our Jedis selected the 7 hackathon teams that did outstanding work on non-functional quality aspects. Security, performance, reliability, maintainability, and whether Blockchain technology was applied in a sensible, future-proof way.

These winning teams were awarded the SIG Investor Readiness Workshop, where we will help the teams prepare their code bases for future funding rounds. Investors are increasingly paying attention to software quality in the due diligence phase of acquisitions. We know, because the SIG Transaction Services team perform so-called IT Due Diligence investigations for investors on a regular basis. In the workshop we help teams to be prepared for that moment.

The 7 teams that built prototypes with outstanding software quality were awarded with the SIG Investor Readiness Workshop. Great job!

• Are you organising a hackathon? — Contact me to discuss how to support the teams with code quality.
• Are you a startup? — Check out the Better Code Hub Starter Pack.
• Are you investing in a software-intensive company? — Get in touch with my colleagues at the SIG Transaction Services team for an IT Due Diligence investigation.
• Are you a CTO or CIO who wants his software development teams to go fast, but sustainably so? — Consider empowering them with Better Code Hub.

Joost Visser is CTO at the Software Improvement Group (SIG), Professor of Large-scale Software Systems at Radboud University, author of O’Reilly books Building Maintainable Software and Building Software Teams, and leading the Better Code Hub team at SIG.

Better Code Hub - GitHub Marketplace_Spend less time fixing bugs. And more time shipping new features_github.com

IT Due Diligence - Software Improvement Group_In a digital world, any due diligence needs to include a rigorous, cost-effective investigation of IT risks and…_www.sig.eu

Building Maintainable Software, Java Edition_Have you ever felt frustrated working with someone else's code? Difficult-to-maintain source code is a big problem in…_shop.oreilly.com