just don’t do it – the art of being lazy

One thing that I find myself doing a lot is skipping a lot of required programming tasks. From what you can find “on the Interwebs”:http://bit.ly/14xsphr only a “lazy programmer”:http://blogoscoped.com/archive/2005-08-24-n14.html “is a”:http://voices.yahoo.com/a-good-programmer-lazy-programmer-692952.html “good programmer”:http://www.codinghorror.com/blog/2005/08/how-to-be-lazy-dumb-and-successful.html!

This does not mean that you should be doing nothing though… it’s all about “getting things done”:http://en.wikipedia.org/wiki/Getting_Things_Done instead of getting stuck in the details!

h2. don’t test your code

I am a huge fan of “BDD”:http://en.wikipedia.org/wiki/Behavior-driven_development and “Test First”:http://www.extremeprogramming.org/rules/testfirst.html. It’s hard writing all those tests when you are lazy. That’s why people tend to write Happy Path tests only.

I think that there are also a lot of areas, where writing tests does not even make sense. IE when you are creating prototypes, learning new frameworks or whole languages and when you are trying to sketch out an object model in code. In those cases, I don’t skip tests altogether, but I defer it to the point where I am confident with what I am going to create.

When you look at large Rails applications they usually have several layers of tests. Unit, Functional, Integration etc. Unfortunately, every layer of tests adds a layer of complexity. I have seen a lot of projects where people write “Capybara Spec”:https://github.com/jnicklas/capybara or “Cucumber Features”:https://github.com/cucumber/cucumber-rails that try to cover the whole application logic! Those test-suites are often brittle and slow, maintenance is a huge PITA. I rather remove those tests and stick with Unit-Tests that might not cover all integration points, but are easy to maintain, understand and also fast.

Use full stack tests only for mission critical features. If you have a good monitoring and deployment process in place, fixing bugs can be cheap. What’s worse, slow and fragile tests, or no tests at all?

h2. don’t refactor your code

I did a lot of refactoring, especially in large legacy systems, some times with no tests as a safety-net. Refactoring is not a value in itself. If a piece of software does it’s job, why would you even think about refactoring it?

“Clean Code”:http://www.clean-code-developer.de/ is something that you want to achieve in every software project. That is because clean code promises to be easier to change and maintain. So it’s not actually about clean, but changeable code. Refactoring code to make it beautiful is waste, always strive to make it more modular and in this regard, easier to change in the future.

I have set up some strickt rules for when I refactor a piece of code:

* I am changing it anyways in order to add a feature or fix a bug.
* I am totally pissed of the way it is implemented!
* I am sitting on a plane and have nothing else to do…

h2. don’t optimize your app

I don’t know how much time I wasted in discussions with other programmers, claiming that this or that part of an application needs some optimization. Most of the time it’s even worse, people implement optimized software right away… This thing, also known as “Premature Optimization”:http://en.wikipedia.org/wiki/Program_optimization#When_to_optimize or how I call it Premature Ejaculation, is most often the source for the NR. 2 reason of why I refactor code (I’m pissed off).

Optimized code tends to be more complex or less readable and in 99% of all implementations, there is a simple, clean, readable and actual faster way to implement it anyways.

Especially code complexity or the complexity that frameworks introduce in order to be super fast comes with a big downside: decreased productivity! It feels like I spent a whole developer year just fixing bugs related to the Rails Asset Pipeline and “I am not the only one”:https://twitter.com/chriseppstein/status/164386237870903296.

h2. don’t think out of the box

It’s a good thing when you are confident with your programming language, you know every shortcut of the IDE that you use, you run a database that you deeply understand and that you are able to tweak, your operating system is up for half a year and you know what buttons to push to keep it running!

There is no value in introducing new technologies to your application stack until you have a real need for it. **Stability and Know-How are often underestimated!** I think it makes absolute sense to squeeze the last drop of performance out of your existing stack, keep it as long as you can!

It’s a different thing for programmers though. Playing with new frameworks, databases, operating systems and coding in different types of IDEs is key for expanding your horizon. Learning a new programming language each year is one of those things, that keeps you up to date and lets you think about coding problems from different perspectives. But do you want to have all those languages, frameworks and databases in your application stack? Is it worth introducing heterogeneous systems to your company’s infrastructure?

h2. don’t automate

There are tons of tasks in your daily workflow that could be automated. Automation is a key factor in terms of productivity. If you want to have fast and sound processes in your business, automation is probably the way to go.

On the opposite, I think that it’s fine to be doing manual tasks! It’s always a tradeoff between the value that the manual task provides, versus the cost that creating an automated tool, it’s maintenance and support costs.

Is it worth setting up a whole CI infrastructure, when all you have is just a single app to test? Well, it depends… As a lazy developer, I would look for “services that do the heavy lifting”:https://travis-ci.org/ for me.

h2. Conclusion

Create something, put some sugar and cream on top, ship it!