So, let’s say you’re participating in the Odyssey Blockchain Hackathon, writing code as fast as possible. Awesome! But let’s pause for a moment and think about tomorrow.
Tomorrow is the day you have to build further with today’s code. You know how it goes. Last night’s mistakes get thrown right in your face. You might utter words like: "Who wrote this code, I can’t work like this?!, only to realize that it was actually YOU. You hack some more until it sort of works… you think… hope… pray… maybe... for now...
Fast forward a few months. You hold your pitch, get some backing and build your prototype into a real-life working application, happily hacking along… and then something breaks. You know what it is, you think. You quickly push a fix to production, and all is well. But 10 minutes later, you get the next call, and before you know it, you’re knee-deep in spaghetti code, trying to decipher last month’s code hieroglyphs. It all comes tumbling down…
Of course, this doom scenario is mostly an exaggeration, but more often than you might think, it’s the bitter reality. That’s why we at Software Improvement Group preach good software quality, religiously. We believe that a little bit of effort now will save a lot of headaches down the road. And we’re helping out at the Odyssey hackathon in two steps:
Step 1: Getting the basics right: Better Code Hub provides a set of 10 basic rules to keep your code maintainable. Can you get a 10/10 score? Last year, 19 teams did it (that’s 30%). So you can, too. Following these guidelines will go a long way in keeping your code easy to maintain in the long run as well.
It’s good to know we didn’t just make this up. All the data and thresholds in our measurements compare your code against thousands of other systems we’ve seen over the past 19 years. If you pass a guideline, it means you’re doing better than the average developer out there. It’s science!
Step 2: Planning for the future: For those scoring a 10, we’ll go one step further: We’ll look at your code, and during a 10-minute grill session, we’ll determine whether your prototype makes technical sense going forward, instead of just looking pretty. This is the “mature prototype” bit on the hackathon canvas. It includes topics such as software architecture and non-functional stuff such as performance, reliability and security.
Sneak preview: One of the questions we’ll ask is: How will this scale? From a technical perspective of course, we don’t care about marketing talk! Handling thousands, millions of users/transactions is not always easy. A little preparation and thinking ahead will definitely save you a lot of problems going forward.
Will you be at the Hackathon? Come by the Jedi corner to say hi, pick our brain, or get grilled to earn the right to call your prototype “mature”. We’re out in force: Me (Jan), Michiel, Jade, Luc, Bugra, Hugo and Reinier. We’re here to help, and we know all about software quality and architecture. It’s what we do!