Episode 31

            As promised, the continuation of Code of Principles is here. This time I’m going to talk about stuff that is less canonical and perhaps not so well known. Today’s motto is that you are not alone. There are strangers, psychopaths, users, fellow developers and good scouts out there.

Don’t talk to strangers

            Let’s discuss Law of Demeter also known as Principle of least knowledge. Proposed in 1987 by Northeastern University, can be informally described in four bullet points:

• You can play with yourself (naughty boy).
• You can play with your own toys (but you can’t take them apart).
• You can play with toys that were given to you.
• And you can play with toys you’ve made yourself.

Which basically means that object should assume as little as possible about its environment, surroundings, its structure, properties and anything else, especially about internal structure of objects it’s manipulating. Classic violations of this rule are chains of invocations like this: a.getB().getC().doSomethin().getD().doSometingElse(); By the way, such style poses additional problems when resolving exceptions. Can you tell which invocation threw one exactly? Code following Law of Demeter tends to be more maintainable and adaptable. Following it strictly has some disadvantages however, like introducing time and space overhead needed to facilitate wrappers and auxiliary access methods.

(P)rinciple (o)f (L)east (A)stonishment

            Also known as (P)rinciple (o)f (L)east (S)urprise. Often used in context of user interfaces from the ergonomics standpoint, along with (D)o (W)hat (I) (M)ean rule coined by Warren Teitelman in the sixties. Regarding user interfaces, people have experience, expectations and mental models. Design should reflect that in being the least surprising as possible. This also applies to code. You should construct things in a way that are intuitive, obvious, consistent, predictable and boring, based on the thing name, location and other clues. Try to leverage existing techniques, standards and conventions as much as possible. What if your project already violates those? Well it depends, if it’s easy to fix, just fix it. If it’s harder, nag your Product Owner for budget to do it. If it’s too hard to fix, follow the bad conventions. Bad conventions are usually better than no conventions at all.

         Good example of intuitive stuff is a ParseInteger(string, radix) method present in many programming languages, that has a one-argument version that usually assumes radix to be 10. Notable exception where it doesn’t work that way is JavaScript, which is… well… JavaScript.

Write Code for the Maintainer

            “Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.” This is somewhat connected to the previous rule. Usually, code is written once and then maintained for a long time. Even if your creations brilliantly fulfill the Open Closed Principle, and don’t need to be modified, still someone has to understand what should be added where to achieve desired result. Think of people who are new to the project and will have to update your code, can they easily do that? Will you be able to do that after a year? When I was working longer on single project I had situations where after finding myself in some strange and scary place I would thought “What kind of moron wrote this crap? Hmm… oh…  it was me a year ago…”. Don’t make me think too much. It hurts my brain.

            Also, Brian Kernighan once said: “Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it”. Keep that in mind.

Boy Scout Rule

            “Leave the code better than you found it”. Boy and Girl Scouts have the rule about camping, namely, they should leave it cleaner than they found it, meaning not only taking care of mess they made, but also of the possible mess they encountered originally. This translates directly to software development. When you arrive at location in code, make sure you don’t leave a mess, as well as try to take care of the mess you have found in the first place. This is a bit tricky. Firstly, you can fix something, spot another thing, fix it, spot another thing and fall into the trap of never ending cleaning further and further away from your camp. This is dangerous, since you stray away from your task goal and thus your sprint’s success might be in jeopardy. Secondly, it’s sometimes risky in legacy (nice word for “shitty”) systems. If you lack automatic tests and wander outside of the area of your task, which will be tested manually, you might break something without noticing. In theory IDE support for automatic refactoring of static language is quite impervious (but not always), however when technologies collide no one is safe. You might change an enum with all its occurrences in Java, but maybe there is a nasty JavaScript code that uses it recklessly on the frontend and boom! you are screwed.

            Boy Scout refactoring should be safe and small, and/or it should happen around the code you are working with. I remember the situation when I walked happily into my manager’s office saying “you know what, I threw away that crappy piece and written it from scratch nicely!” and instead of joy I saw grim face and heard “I didn’t ask you to do that…we have budget and stuff…”. I had to explain in details that I was building upon that change and I can deliver things faster now, and it was safe and good thing in general. If you spot a bigger refactoring opportunity outside of scope of your current task (say more than one hour of coding, depending on your team’s work agreement, deadlines, sprint tension and all such things), don’t rush into being good Boy Scout, ask your Product Owner if it’s okay and add it as a separate story to sprint. Remember, we are not here for the sake of art (unfortunately) but to fulfill our client expectations. We can shape those expectation too of course.

Finally

            Think before you commit. Do they know where you live? Should you be scared if they do? Don’t worry, stick with the dragon blog and you will be fine ;)