E-mail Practice & Code

I remember reading somewhere: Software reflects the organization that made it. The quality of  the code says a lot about the practices of the organization (company, team, individual) that created it. After all, quality of code is the result of software practices.

The opposite is equally true. The practices of an organization say a lot about its software practices.

Practices are the result of values, of world views, held as individuals and, in the aggregate, by an organization.

One practice that I have found to be specially revealing is the handling of email threads.

Anti-Patterns

• If threads need to be measured "by-the-yard", will functions in the code be any different?
• If subject fields are not indicative of the contents of an email, will function and variable names be any different?
• If mail threads are not forked, will code be re-factored?
• If sentences run on and on, will the code be any less convoluted?
• If paragraphing is poorly done, will code structure be done well?
• If mail is not self-reviewed, will code have unit tests?
• Most importantly, if the CEO and CTO tolerate sloppy email, will they do anything about sloppy code?

Takeaway

Code is written - just like a document is written. Code is constructed - just like a document is constructed. Both require thinking. Careless thinking for one is a good indicator it will be so for the other.

Lessons from the Commonwealth Games: Hygeine

Lalit Bhanot, of the Organizing committee is reported to have said that our sense of hygiene differs from that of the other nations participating in the games. Some people, not unexpectedly, have been offended by that.

Let us take it that Mr. Bhanot was not taking of personal hygiene but rather of public hygiene. It would not surprise me if even that was contested by people responsible for public hygiene. I am sure they could come up with certificates that say that public hygiene is world class. It would surprise many that Noida has an ISO 9001 certification.

Certification is a one-off, or at best annual, event. A process has to be lived 24 x 7.

Bad hygiene, private or public, usually manifests itself as a bad odour. Bad code "hygiene" too usually manifest themselves as coding smells.

AntiPatterns are very closely related to coding smells.

Many years ago, acmet's Tools BU was confident it was doing good work for its Japanese customer. There was a regular flow of defects coming in, but the customer was not complaining about quality. Being Japanese they would have considered that rude. They hinted. We did not get the hint. One day the customer could not stand the "smell" any longer. They told us bluntly. That is when we started to improve our software development hygiene.

The regular flow of defects was a process anti-pattern that we failed to sniff (I apologize for mixing  metaphors:-). As with personal hygiene, most times there will be no clear message for bad process hygiene. Learn to read the small tell-tale signs. Be paranoid.

Lessons
Get QA and developers to sensitize their noses to detect project and coding smells.
Certifications breeds smugness. Live the process 24 x 7.