I’m not a great programmer; I’m just a good programmer with great habits. — Kent Beck> Quality of code may not guarantee the success of a project, but it can definitively be its main, though invisible, cause of failure. — Mario Fusco
The Blockchain Hackathon
In the second weekend of February, 50 teams will compete in the Dutch Blockchain Hackathon. Over a 54-hour stretch, they will unleash their creativity to build innovative blockchain-based solutions that may shape the future of our society.
The teams will compete in 5 thematic tracks, vying for praise and recognition by the jury, and for €50,000 in prize money.
The jury will be looking for quality, impact and contribution to the blockchain ecosystem. Teams can earn bonus points by using open standards and sharing their code through open source licenses. And by producing high-quality code.
Why is code quality important?
So why is code quality important in this hackathon? Are hackathons not intended to hack things together until they work? Not to produce something polished and future-proof?
Well, here are some reasons code quality is not a luxury.
- Blockchain is based on trust. Or, as Ravish Gopal explains, with Blockchain, “the conventional trusted third party mechanism is being replaced by software”. And trust requires auditability. Better code is more auditable.
- Innovative solutions, whether built by startups or established organisations, must be adaptable, extensible, and transferable. Otherwise the solution will not outlive the startup founders and/or the first team that works on it.
- In general, better code allows you to build better products. Rather, as argued by Rob van der Leek, great products are not built by great individuals, but by great teams. And good code is both the hallmark of a great team and a necessary precondition for their successful operation as a team.
Well, you may say, these reasons only kick in after some time, not before my hackathon is over. So let’s narrow our focus to the first 54 hours of your team’s project. Why is code quality relevant?
- Lunch : Good code starts paying back before lunch on the first day. By that time you are no longer in your first iteration. You are modifying and enhancing the code you wrote in the morning. If it’s messy, hard to read, untested, bloated, and so forth, then you will slow down, inject defects without noticing, and lose your way.
- Dinner. Bad code makes your team hate you before dinner. The code you wrote looks weird and alien to your teammate that wants to build on it. Before adding to it, she needs to refactor. You don’t like what she does to your code. Rather than complementing each other you enter into a turf war.
- 36-hours in. You just had your breakthrough idea that will set you apart from the competition and impress the jury beyond belief. Except that changing your code to implement this idea seems like jumping off a cliff. Your code is a house of cards. Should you refactor, reorganise, make the required changes? Or rather start over. Time is ticking.
- Win. You pulled it off. Your solution works, it wows the jury, and you’re are invited for the post-hackathon accelerator track. But wait! Though it works, you don’t know why or how. Some of your team members won’t hang around after the hackathon, but their code is a mystery to the others. In a way, you still come out of the event empty-handed.
Can code quality be measured?
Given the importance of code quality for teams to build great products, we need a shared definition of what code quality is and how it can be measured.
An abstract definition of code quality can be found in the notion of maintainability as provided by the ISO 25010 standard on software product quality:
maintainability = degree of effectiveness and efficiency with which a product or system can be modified by the intended maintainers, where modifications can include corrections, improvements or adaptation — ISO 25010
We have operationalised this abstract definition in a concrete set of measurements, complete with thresholds and aggregation to a simple rating scheme (see “A practical model for measuring maintainability”, IEEE Computer Society Press, 2007).
In turn, this measurement model has been the basis for 10 guidelines for the working programmer, published in “Building Maintainable Software” (O’Reilly, 2016).
At the Software Improvement Group, we have been using and improving our maintainability model over a decade to measure billions of lines of code and provide hundreds of executive clients with fact-based advice on how to manage their software projects and application portfolios.
So, yes, code quality can be measured.
Plenty of tools are available for measuring code quality. But they come with pitfalls. They often measure the wrong things by default and require intricate configuration, and they flood the developer with false positives, i.e. warnings that don’t reveal any real problem (for a more detailed discussion, see my success criteria for applying software analysis tools effectively).
To avoid these pitfalls for developers, we have developed the Better Code Hub. It provides developers with immediate feedback on the 10 guidelines. We designed Better Code Hub to be extremely easy to use, provide a clear definition of done, and empower teams to improve what matters.
The guidelines set crips thresholds, but they also provide tolerance for the occasional outlier. As a result, the definition of done provided by Better Code Hub is challenging, yet achievable and fun.
The teams participating in the Dutch Blockchain Hackathon are stimulated and supported to innovate with high quality code. Support includes:
- Books. Free copies of Building Maintainable Software will be distributed to the participants.
- Better Code Hub. The teams will get 12-month Pro access to the Better Code Hub.
- Assistance. During the event, a team of SIG consultants will help participants use the tool, and coach them on code quality.
- Jury. The measurement results of Better Code Hub will be made available to the jury, allowing them to award bonus points for higher quality.
Is code quality relevant beyond this hackathon?
Software is the DNA of our digital society. So yes, code quality is important for all of us. Competitive power and business agility depend on mastery of software.
If you are not participating in the Hackathon, but you are interested in measuring and managing code quality, here are some options:
- If you are a start-up , we have a complimentary Pro license for Better Code Hub for you as well (conditions apply).
- If you are an open-source developer, you can use the Free license on any public GitHub repository, within reasonable size limitations.
- If you are an IT director, development team lead, or similar , let me know about your challenges regarding code quality, developer competencies, team empowerment, software governance, application portfolio management, etc. At the Software Improvement Group, we know what it takes to be successful in both empowering self-organising teams and applying effective governance over your in-house software development, your suppliers, and your IT landscape.
Joost Visser is CTO at the Software Improvement Group, Professor of Large-scale Software Systems at Radboud University, and author of O’Reilly books “Building Maintainable Software” and “Building Software Teams”.
- Building Maintainable Software, Java Edition
- Building Maintainable Software, C# Edition
- Building Software Teams
- Dutch Blockchain Hackathon Community