That's how it should be?

If I had R10 or a dollar, for the amount of times developers assume something because they say it "should" be like that, I would be rich.

I must admit, I find it a bit weird that they assume things because it is how it "should" be as if the computer is morally obliged to be like that. We say things like "It should rain tomorrow" or "You should not steal"... implying either that there is some uncertainty to the statement or that it is a recommended thing to do.

Notice that with the use of "should" there is NO certainty - why I find it strange that developers even use the word "should" with reference to code. Developers should only be talking in absolutes when talking about code behaviour, and until they can talk in absolutes they should keep their mouth shut.

After all, they have the code in front of them; they can look at it - if it's a spec they're looking at, yes, the behaviour specified in the spec "should" (correct use) be what the code does. That is how things are setup, but if you have the code in front of you, I don't want to hear "should". Why take the risk of the "should".

Just today this is what happened. A method was taking a string and the string was called "status". Now there is also an Enum called "status", and the developer figured well, that "status" and the enum status should both have the same "toString". iow, the toString of the enum should map to the valid strings that the method understands... a big should. If that is the case then why does the method not take an enum.

Now, yes, it should be like that, but is it? In this context I'm not interested in should. This shouldn't cause a bug is just not good enough.

A cursory glance at the code should, oh sorry, can, often lead to the resolution of the doubt, and in this case, the assumption was proved wrong, causing a time wasting bug.

So in a development environment when one is asking how is the code behaving, one should never hear "should".

Best Practices are for people who don't know what they're doing

On my last project, I can remember occasionally reading through "best practices" of the various technologies we were using. Spring and hibernate spring to mind.

I can remember noting that we were not following a large number of the best practices. In fact, what is more interesting is that we had made those decisions without considering the so called "best practices".

However we did not make those decisions without considering all the variables. In each instance where we diverted from the best practice we did so for good reason and with our eyes open. In other words, we did not deviate from best practices because we were rebellious but because we knew what we were doing. In all cases we had a ready defense for not using the best practice.

I realised in doing this that the point of best practices is to protect the person who does not quite understand what they're doing, to make sure they don't really shoot themselves in the foot. For those people who understand the situation, best practices are useful because they provide a base to work from. If you deviate from best practices make sure you can defend your deviance.

Furthermore, I'd also like to add, that very often a so called best practice is someone's opinion. A few months ago I wrote on what I thought were hibernate "best practices". These are based on my experience and my opinion, they are my best practices not necessarily industry tried and tested best practices. So the label "best practice" is often a fairly loose term.

Best practices are for people who don't know what they're doing, but for people that do, the tried and tested ones are a good and worthy starting point that should only be deviated from for good reason.