Subscribe via RSS

3 Simple Ways To Avoid Making Code Smells

Filed Under Quality Controls

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.

RSS Icon

  Don't miss a drop! Subscribe now via RSS or email.

Comments

One Response to “3 Simple Ways To Avoid Making Code Smells”

  1. Jeremy N on October 20th, 2007 7:40 am

    @Point 2
    I feel one of the continuous/BIGGEST failures of developers/project managers/business analysts is the
    “unwillingness” to tell clients/managers what it will take to make a change in a project. We need to spend time before the project training our clients/managers that changes will have consequences. Then when they come with changes, which they will come with changes, don’t worry about deciding for them, just give them the fully loaded amount of work that it will take to CORRECTLY do the change (including refactoring).

    If you trained them correctly they should realize that the closer to the completion of the project the more impact that change will have.

Max Pool - © 2024 - {codesqueeze}. Sycorr Banking Solutions