Occam’s Razor Sharp Code Or Nothing
A while back, I had to step into a project which had been going on for a while which needed saving – the code was spaghetti, so convoluted and rife with dependencies and weird things. The developer went over the top, adding layer after layer of complexity to what should have been a simple thing, using a crazy amount of plug-ins, add-ons, multiple libraries and so on and so forth.
Just going through the code and attempting to understand it was hard enough. The code was barely documented, and even though the guy who wrote the original code was still on the team, he we very reluctant to give up any information as to how or why he did what he did: even requests to provide a full and detailed description of the flow of the app were met with silence. The only thing he did do was give out just enough information to proceed to the next step of analysis, after which we’d have to ask him for more detail.
He also played a trick which I’d seen the mom on Everybody Loves Raymond did (my wife and I have been marathoning the series at the time) she gave up her family recipe for something to her daughter-in-law, but since she didn’t really want her daughter-in-law’s cooking to surpass hers, she changed a key ingredient in order for her daughter-in-law’s version of the dish to fail. This developer did the same thing – leaving out critical bits of information, forcing us to keep going back to him for it – or giving us the wrong information.
It was a nightmare. In the end, we had to basically re-write the whole thing from scratch. As it turned out, only about 10% of the code actually did something – the rest was extraneous crap that didn’t even need to be there.
I’m an Occam’s Razor kind of guy. The simplest solution is always the best. The minimum product that you can launch is the one with the least amount of features which delivers the experience you want to deliver. And code should be written in the simplest possible way in order the deliver that product.
Too often, developers look to some future proposed end or later state of the software, and attempt to build the framework for that later state, resulting in a crap-ton of extra stuff in the code you just really don’t need now – and may never need, if the requirements change and you have to pivot.
No, the key is – write fast, write simple, and explain what you are doing every step of the way. And write for the product you are shipping today, not tomorrow.
Latest posts by Chris Kalaboukis (see all)
- How to Innovate by Breaking the Law - January 19, 2017
- INNOVATION MASTERY: Putting The Players In Place: The Program Manager [VIDEO] - January 18, 2017
- Say Goodbye To Privacy From The ChatBots of the Future - January 17, 2017