Stop Blaming Lazy Developers for Language Flaws

DZone 's Guide to

Stop Blaming Lazy Developers for Language Flaws

Lazy developers are absolutely a problem, but some flaws in older languages in Java make development much much harder than it should be. That's hardly the dev's fault.

· Agile Zone ·
Free Resource

In response to a number of posts I’ve both written and read people seem to deplore the idea of laziness in a developer. Take this comment from my article on code conventions:

“... just because programmers are lazy and don’t want to comment their code, or update the comments when changes are made it does not mean they should not be created to begin with”

I believe that these statements are fundamentally wrong. If we see a repeated behavior such as a mishandling of exceptions or out of date comments, it should not be viewed as a failure of individual programmers, but as a serious smell; these are anti-pattterns which have an underlying cause that must be fixed. The solution is not to patch the symptom but to fix the actual issue. This is not laziness.

One of my biggest bugbears is poorly designed forms on websites. These are the sites where, when one field is wrong it wipes out all the data. These are the forms that say a field is not mandatory, but will not let you advance until they are filled even though they aren’t relevant. These are the forms that have validation but won’t tell you what the correct format is so you can’t get past them.

These are the websites that cause so much of the population to say “I’m rubbish with technology”.  To apply the lazy programmer analogy we would be saying that the problem here is the person's inability to fill out the form. They’re just not good enough! Of course this is ridiculous. The problem is that the form was badly designed and someone should have been fired for it.

Saying that comments are great but developers are lazy is equivalent of saying “My application is amazing! If only the people would use it correctly!”. It is blaming the people for torrenting Game of Thrones outside of the US when the episodes aren’t going to be shown for 2 weeks or more in their country. The simple fact is that code comments do not work. They go out of date quickly, they get lost in the wrong place during refactorings, and they cause more pain than benefit. What’s the solution? Clean code, thorough tests, and well named methods and variables.

The same goes for Exceptions. It’s well known Checked Exceptions are handled terribly by developers. This is not the developers fault, it is caused by checked exceptions being inherently flawed. There’s a reason no language since Java has used them. Yet people keep blaming developers for being "lazy".  Any developer worth her or his salt knows they need to correctly handle application problems and deal with them in a clear manner. But when APIs throw Checked Exceptions you know you’ll never hit, or you can't/don’t need to deal with then you’re going to end up with a bunch of empty or logging catch blocks. This antipattern then results in bugs because people are complacent because the boilerplate try catch code is all over the codebase. Remove Checked Exceptions and people have to go back to consciously dealing with exceptional circumstances in a proper way.

So "laziness" is a great way to sniff out anti-patterns in the code base. But it is also something that should be lauded in a programmer. A few months ago there was an article kicking around the internet about the developer who automated everything, including emails home to his wife to say that he was going to be late. This is the dream, and what we should all be aiming for.  Repetitive tasks are the enemy. Manual processes are the bad guy. Having to manually create a report every week is a bad use of an expensive developers time.  The calling card of the "lazy" developer is the automation of all tasks that take away from our valuable programming time. This is exactly who you want on your team.  

automation, comments, exceptions, productivity

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}