Month: February 2012

We all know it is a good idea to follow best practices, but we also know that we don’t always follow it. I find that interesting.
Now, when I want to change something, I find it helpful to understand why things are the way they are. It is worth asking, then, why don’t we follow best practice? And what can I do about it?

Ignorance

Simply not knowing what constitutes best practice appears to be a reasonable excuse for not following best practice. For someone new to the discipline, this is fair. But what about those of us who have been in the profession for some time? Is it enough to argue that nobody has shown us the way? That nobody has made the information we need available to us? Well, I do sympathize with people who face these issues. But only to some extent.
The truth is, my career is my responsibility. I have a professional responsibility to develop our skills in our chosen craft, and we live in an age where this information is more readily available than it might have been in the past. I can choose to learn if I want to.

Pressure to Deliver

My client needs a solution delivered yesterday, and my family needs me at home in the evening. When am I supposed to learn, let alone implement, best practices?
Actually, the problem for the company is not lack of time. It is lack of understanding. The reason I say this is that best practices, by definition, deliver more value for less cost. If they didn’t, they wouldn’t be best practices. The way to deal with this, issue, then, is to find ways to communicate the benefits of best practice to the people around us – having firmly established what best practice actually is as it applies to our situation. We need to persuade managers that a small investment now – a delayed delivery – will reap long-term benefits.

Take time to go fast.

Part of the solution is to recognize  that developing my skills isn’t my responsibility alone. My employer has a responsibility to support my personal development – to give me time and resource to grow so that I can add more value to the company. Sometimes, however, organizational leaders need to be reminded of this. I may have to persuade my managers that allowing me resource to grow will benefit them in the long term.

Other Developers

I am led to believe that, sometimes, other professionals actually foster ignorance of best practice. They may feel threatened by having to learn new skills or by their own practice being challenged. They may feel that they already know best, that their methods are tried and tested. They may have worked hard to develop their own practice, and as a result have formed a strong emotional attachment to the way things are done at the moment. I imagine that it takes strong leadership skills to overcome such challenges. If you face this problem (and you’re sure that the practices you propose actually are the best ones) you may want to take a course in influencing people along with your studies in professional practice. As for me, I’m fortunate that I work with like-minded people. Assuming my colleagues don’t think that I’m one of those…

Conclusion

First, I see that there are two directions from which my behavior is influenced:

• From within – by my own assumptions and feelings and understanding
• By my external environment – the systems and relationships that surround me

I recognize that I need to deal with both of these areas.
Second,  it seems that professional quality is not a technical problem but a people problem. To develop it, I need to develop myself and my relationships with the people around me. Which is interesting in itself. The reason I got into technology because I didn’t really see myself as a people-person. It seems I was mistaken: I’m do a technical job, so I must be a people-person after all.

Naming Matters

For programmers, naming is an important activity:

• It has a significant impact on code readability
• We do it a lot

General Principles

• Don’t make me think
• Make wrong things look wrong
• Take time to go fast

General Guidelines

• Don’t be a perfectionist – don’t let naming paralize you
• If you can improve it, do so
• Remove the comment and improve the name
• The wider the scope the longer the name

Follow Standards

• Follow platform conventions
• Call things the same as they are usually called
• Use programmer speak for programmer things (solution domain)
• Use the customer’s language to describe the customer’s things (problem domain)
• Spell consistently and correctly
• Pick one word to describe a concept and stick to it
• Don’t inventing language where you don’t need to

Encourage Communication

• Use pronouncable names
• Invent language where you need to
• Don’t be cute, clever or funny: not everyone will get it
• Avoid cultural references

Be Useful

• Avoid disinformation
• Avoid noise words – words that don’t add anything (a, the etc.)
• Avoid redundancy
• Use searchable names
• Think sortability – this will depend on the IDE
• Avoid hungarian – it doesn’t usually add anything
• Add context where it helps, remove it where it doesn’t

Specific Scenarios

• Class names: noun-phrases, not a verbs
• Method names: verb-phrases, not nouns

Further Reading

• “Clean Code” by Robert C. Martin, a version of which is available on the ObjectMentor web site.