I am an exceptionally lazy developer. If you look at my code, you’ll find that I mercilessly cut corners, fail to implement obvious features, and my big O sometimes careens wildly out of control. Why am I so lazy?
When I began my career I was the opposite of lazy. I tried to future-proof my code by designing complicated systems that anticipated our undefined needs. I carefully scrutinized every loop and allocation for stray operations that would impact performance. Like a freshman vying for extra credit, I piled on features like there was no tomorrow. Gradually, I came to understand that my efforts were misguided:
- future-proofing rarely works, because the product inevitably evolves in unforseen ways. You’re likely to end up with a bridge to nowhere. Also, the wacky futuristic code that you write will be untestable and buggy. Future-proofing is an example of over engineering, where well-meaning engineers mess things up by trying too hard.
- premature optimization is another no-no. Optimized code is more difficult to write, debug, and test, and always ends up buggier than unoptimized code. Just turning on optimization in the compiler can sometimes lead to horrible bugs. Instead of optimizing every line, find and fix the bottlenecks. It’s more satisfying that way anyhow.
- extra features probably won’t earn you any bonus points. Your features might not get used, and you’re definitely creating more bugs for your poor QA team to squash. This is another example of over engineering.
Writing software is a constant battle against complexity. Complexity kills. Complexity kills testing, deadlines, products, careers, and companies. Each additional line of code increases complexity. In the pursuit of excellence, senior developers must constantly strive to eliminate features that aren’t absolutely necessary.
Cultivating laziness is the easiest way to combat complexity. The lazy developer doesn’t need to show off by tossing more features onto the pile. The lazy developer optimizes intelligently instead of trying to perfect each line. The lazy developer hesitates before deploying complex and indecipherable algorithms.
By now most of you are probably nodding your heads (or nodding off). But clearly there are people who don’t get it, because I’m constantly running into complicated, over engineered software written by developers who are trying too hard.
Future posts will illustrate with some anecdotes. Names will be omitted to protect the guilty.
You lazy bum.
Are you going to have a “keep it simple” thread as well? That’s my problem. I sit and I think just like Winnie the Pooh, Think … think … think … tapping my head all the while, trying to keep it nice and simple. And it ends up complicated anyway. It’s think it’s a side-effect of not seeing the big picture, even when it’s the big picture of that small subset of the whole problem.
Pingback: Bogle’s Blog » Adam Doppelt’s Blog
Pingback: alexking.org: Blog > Around the web
I also like the corollary that if you don’t get it, don’t implement it. Ray and I worked on a complicated email/cookie based authentication system. While I was working on it, I got confused and had to draw a flow chart to keep track of the differnt paths through the system. The name of that feature is now our euphemism for ‘way too complicated.’
Ditto, to the nth degree. Now try convincing management.
Lazyness stems from the “desire to have a break”
When you realize that you CANNOT possibly have a “break”, repel the desire for a break, and the lazyness will go away. If you dont WANT a break, you CANNOT be lazy.