I was pondering about how quick hacks can contribute to code destabilization and the previous post The Dangers of Git R’ Done. How many hacks or code smells should be allowed per project? The obvious theoretical answer is none, but the realistic answer is too many. Here are 3 easy ways to reduce the number of hacks and code smells in your projects.

1. Eliminate gold plating

I looked over the artifacts for my last couple projects in order to find some insight. Habitually, I allowed 1-2 moderate to high smell hacks per project. Further investigation found these hacks were implemented during the last iterations of each respective project.

Late game hacks are not an uncommon thing; however I did find the correlation between end game gold plating and these hacks interesting. Over the past couple of years, every hack was associated with a gold plated requirement (both developer and client initiated).

The mere speak of the acronyms YAGNI and KISS should send gold plating packing. Awareness of budget and quality impacts is also great motivation for not allowing gold plating and feature creep.

2. Negotiate for time to refactor

Lots to do, with very little time. How you handle this situation will determine if you will be adding new features or new code smells.

Repeat after me:

“After the core requirements are complete, I do not have to cram all of the enhancements only using the remaining budget.”

Negotiate with the client or management to prioritize the remaining requirements. This will give you the time you need to complete as many as you can correctly.

3. Go heavy on unit testing and documentation

Push comes to shove and it is time to throw in a hack. Unit test it harder than normal, and never assume people will be able to follow the hack through code so document it more than normal. Personally, I explicitly use the notation //HACK just as much as I use //TODO.

In short, code smells and hacks are just like mother-in-laws. The best way to handle them is to just avoid them all together. If that is not possible, negotiation, documentation, and testing will make a ton of difference. Happy Coding.

A few blogs such as FreelanceSwitch and Zen Habits have written about ways to improve morning productivity. These posts intrigued me to analyze my morning ritual as a blogging developer.

First off, I am a night owl by nature and very slow to start in the morning. At least 30 minutes of mindless shuffling in the kitchen must occur before my brain turns on. Consequently, my old morning ritual was:

• 7:00 AM – Wake up
• 7:15 AM – Feed the dog and then myself
• 7:30 AM – Clean up and commute
• 8:00 AM – Start Outlook
• 8:30 AM – Start Google Reader
• 10:15 AM – Break time from reading RSS
• 10:30 AM – Start working

My flawed morning ritual produced unproductive mornings followed by very sluggish moving afternoons. Promising myself a change, I laid down 3 rules: learn how to wake up earlier, blog before work, and no RSS before my Most Important Task (MIT) was completed. My morning ritual slowly evolved to:

• 5:00 AM – Wake up, grab a banana, head to my home office
• 5:05 AM – Quickly check blog stats
• 5:10 AM – Write blog posts using Dark Room
• 7:15 AM – Feed the dog and then myself
• 7:30 AM – Clean up and commute
• 8:00 AM – Start Outlook and respond to only urgent messages
• 8:05 AM – Shutdown Outlook
• 8:10 AM – Start working by tackling my MIT
• 10:15 AM – Reward myself with a 15 minute Google Reader break
• 10:30 AM – Clean out my email inbox

This schedule is very rewarding due to the increase in productivity. I have accomplished my largest personal online MIT (blogging) and my professional MIT all before lunch.

You do not have to be an early bird in order to have a morning ritual. Anyone can benefit from a ritual regardless of when your day starts. Try the 3 rules of getting some sleep, stay away from email and RSS, and tackle your MIT. Hopefully, you will find your days much more efficient.

After reading a post titled “Why I Don’t Wear a Suit“, I challenged myself to figure out how much salary I would sacrifice for never having to wear a tie.

Every year I pass up $15,000 and I am wealthier for it.

It is commonly misunderstood that money and wealth are the same thing. The reality of money is that it exists as a measurement tool, the same goes for inches, hours, or grams. Money is a way of measuring wealth but is not wealth itself. As explained in the book Does It Matter?:

A chest of gold coins or a fat wallet is of no use whatsoever to a wrecked sailor alone on a raft. He needs ‘real’ wealth, in the form of a fishing rod, a compass, an outboard motor with gas, and a female companion. – Alan Watts

Personally, not wearing uncomfortable slacks is a single act of enrichment; thus wealth. Everyday I use up-to-date software development practices (Agile, SCRUM, TDD, etc) with people I consider friends. I work at a wealthy company.

Other companies compensate their lack of wealth by providing more money. Which reasons am I willing to sell out on? If I was to break this down:

• $15,000 – Not having to wear a tie
• $10,000 – Develop without Continuous Integration
• $15,000 – Develop without unit tests
• $40,000 – Develop without source control

So for an extra $80,000 a year, I will code without honor while wearing a tie. Until then, my wealth will come in the form of working with friends, purity to the software process, and wearing my PJs to work.