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.