Important Lesson about R&D
Working as the director of R&D for Ellem has taught me many things. Leadership in general has always had a type of learning curve that only resolves in frustrating and repetitive conversations. Research and Development is just another layer to add to the organized chaos.
The first lesson I learned that would have suited my in my software development days is the “50% rule”, a quote from CEO of Stack Overflow, Joel Spolsky:
A 50%-good solution that people actually have solves more problems and survives longer than a 99% solution that nobody has because it’s in your lab where you’re endlessly polishing the damn thing. Shipping is a feature. A really important feature. Your product must have it.
I’m not one to change my way of doing thing just on a single quote been then I saw another by Reid Hoffman, Founder of Linked:
If you are not embarrassed by the first version of your product, you’ve launched too late.
Then I reflected on my history in R&D in general and started to simulate this principle. It was clear I was a victim of the “99%” trap; I would continuously try to perfect something instead of moving to finish it. And that 100% is truly not obtainable, it’s an exponential grind. For example, it takes 2 months to get from 0% to 50%, 2 more months to get to 75%, 2 more months to get to 87.5%, ect. By the time you reach 99.8% you’ve been beat by the guy who released the 50% solution a year earlier.
So I applied it to my work and I’ve only seen incredible success unlike anything I would have thought in my early career. So I’d like to distribute my very own rule:
Finish now, complete later.
What could go wrong with that rule…
Technical Debt should be called Technical Impurities
Yes. The hardest thing to manage the higher you go in the leadership chain. Oddly enough though, even when following my aforementioned rule, I don’t often run into technical debt problems. Under my direction so far my teams have never got critical over “cruft” in their code. I’m sure this is because I have many years of dealing with technical debt myself I’ve learned what to do in a management perspective in order to mitigate it, if not completely eliminated it.
The first thing you have to do is treat technical debt as not as a debt. The debt analogy works well from the perspective of the manager, that is when software engineers take shortcuts it always come’s back to haunt them (like taking out a loan).
Instead, it’s better to treat technical debt as “impurities” in code. Bad code that makes technical debt is known as “cruft”. And I see every “cruft” line as an impurity in the overall product - which is in this analogy, the overall product is a metal, perhaps.
When working with software with to much impurities, it will only be useful in small applications, but cheap to manufacture. Larger and more serious applications must have as little impurities as possible, otherwise development will grow in cost exponentially due to a faulty foundation and structure.
FOR EXAMPLE. You can build the frame of a house out of wood. But would you do the same with a sky scraper? Wood is easy to get, and steal is not. But that doesn’t mean a wooden sky scraper is easier to build. Same goes with out-of-college software vs consultant software.
Also, look at this article by Martin Fowler. Here he outlines some pretty impressive insight on cruft and technical debt. Ie.,
How to minimize Technical Impurities
There. Are. Thousands of ways. There’s tricks, techniques, methods, secrets, and processes as there are with reducing impurities in manufacturing aluminum. It’s my belief that the methods I have found will advice Ellem Laboratories to the next level. Because these are trade secrets I can’t share them. But there’s a few - more obvious - tricks you can do to minimize technical impurities
- Peer-review of code
- Automated test driven development
- Choosing the right language, not the popular one
- Automated code-format inspection
There are many things I could list, but again, this information is a trade secret. Google has their way, Amazon has theirs, I have mine. No software company will offer you help on minimizing code impurities because it’s the only way they can deliver unique solutions that are so much higher quality than anyone else’s.