Bulldozer00's Blog

I was at a meeting once where a peer boasted: “It’s hard to schedule and convene code reviews when you’re writing 2000 lines of code a day“. Before I could open my big fat mouth, a fellow colleague beat me to the punch: “Maybe you shouldn’t be writing 2000 lines of code per day“.

Unless they run a pure software company (e.g. Google, Microsoft, Facebook), executive management is most likely a fan of cranking out more and more lines of code per day. Because of this, and the fact that cranking out more lines of code than the next guy gives them a warm and fuzzy feeling, I suspect that many developers have a similar mindset as my boastful peer.

Unsurprisingly, the results of cranking out as much code per day as one can, can yield legacy code before it actually becomes legacy code:

• Huge classes and multi-page member functions with deeply nested “if” constructs inter-twined within multiple “for” loops.
• A seemingly random mix of public and private member objects.
• No comments.
• Inconsistent member and function naming.
• No unit tests.
• Loads of hard-coded magic numbers and strings.
• Tens of import statements.

Both I and you know this because because we’ve had to dive into freshly created cesspools with those “qualities” to add new functionality – even though “the code is only a tool” that isn’t a formal deliverable. In fact, we’ve most likely created some pre-legacy, legacy code cesspools ourselves.