Good software trumps elaborate code. And unfortunately, you can’t usually have both. The real world has deadlines and ship dates. It’s a game of pick two:
- Ship on time
- Ship with elaborate code
- Ship with a fantastic product
Almost always, you should pick the first and the last when you’re building software applications for users (if you’re building API’s or open source libraries for other developers, then it’s a different story).
And he’s right. When you work in the world of commercial software you can’t do it all. I’ve worked with people who want to write the world’s best software and would make other engineers swoon at the glory of that code… but does that help us make a better product? Does that help us ship? Because you need to ship sooner or later because you need to make money to keep the lights on so you can keep writing that gorgeous code.
I used to be this way, wanting to write the best code possible, but a manager early on in my career set me straight about this need for balance. Yes we need to write good code, but it needs to be “good enough” to allow us to ship and manage the problems before us. Plus, the most well-designed code in the world may not be so well-designed when you look at it a couple of years from now — when your needs change. I learned you cannot predict the future and you shouldn’t try to code for the future because needs will change and be something other than you anticipated. That doesn’t mean you should write sloppy code. You can still write good code, you just have to find the balance between writing this “ivory tower” ideal code vs. the realities of needing to ship, because all code takes time to write, rewrite, and maintain.
Plus, consider that writing code is and should be an iterative process. You write something today, get it out the door, then you can work to improve things down the line as needed. You’ll always encounter things you didn’t anticipate before, you’ll find a better way to do things. You’ll add some new feature that can leverage some other part of code so now it’s time to refactor… and would it have been worthwhile to do all that work to make some ideal code that ended up being thrown out because needs changed? Maybe, maybe not. Again, it’s about finding the balance in writing code… and that just comes with time, experience, and shipping.
Seek balance in this so you can write “good enough” code, and still ship so you can keep making money so you can keep on writing code.