Have you ever been on a walk in a ski resort town right smack in the middle of winter. I used to go to Mammoth Mountain, California quite a bit to ski when I was younger. I used to love taking a shuttle into the heart of the town and going for a brisk walk at night. Everything was covered in snow. I can still hear the sound of the snow "crunching" as I walked across it on my way to a local restaurant or in and out of shops. The best part was when it would just start to snow and you'd see the snowflakes fall. I'd reach out and catch one and look at it. A smile would come across my face as I made out all the little branches of it. I'd think, "Wow! they say there are no two that are alike." So nice.
Reality check...(insert sound of scratchy record).... Back to work.
Well, snowflakes may be beautiful in Mammoth, but when you find one in your code, its a friggin' nightmare.
So, what is a snowflake? Well, once again I have to give credit to my good friend Igor who came up with this term. (the guy really is a genius).
A snowflake happens when people who either don't understand or care about the underlying software architecture begin taking short cuts they shouldn't be taking. They compromise the code-base by creating little branches of code that hang off the core to do a specific thing, a kind of
"one-off sort-of thing that's like that other thing in there, but I don't want to figure that out, so I'll just put this little thing in here so I can be done with this and move on to the next thing."
Rather than take the time to engineer the solution in the correct place, they take the path of least resistance and decide to invent a solution with disregard for enhancing or fixing the code where it belongs. Through ignorance or negligence, they have little regard for the impact of their actions.
Now, doing that once doesn't really constitute a snowflake. ... even doing it many times doesn't... That just makes the code sloppy. The snowflake occurs when you start compounding the branch, by adding more and more dependent code branches that hang off the branch, and the underlying circumstances or assumptions within the code are just plain wrong.
If an organization allows this to happen for too long, the problem becomes insurmountable. The bad assumptions are compounded over and over again and your team will become paralyzed. The snowflake becomes so large, that when you ask your staff to fix it, they'll tell you it can't be done or they don't know how. Here's another hint, when you ask for something you think is a reasonable request, they tell you it will take millions of dollars. It goes something like this:
You: "Hey, how long do you think it would take us to change this address validation?"
Developer: "Here, or everywhere in the code?"
(Not a good sign)
Developer: Probably 2 months and $100k.
You: "Uhuh. $#^&! We have a friggin' snowflake on our hands."
That's why it's a good practice to refactor. Let me be clear about this... Don't refactor every once in awhile.... (make a big smile) ... Like having a "special refactoring sprint." (hold that smile)
(stop smiling... look very serious)... Nope!....(still serious).
ALWAYS refactor.
Refactor like you are a Banzai tree grower shaping a tree or pulling the weeds out of your rice paddy. Keep the code pristine. There is NO room for snowflakes in software.
ALWAYS refactor.
When you get to the point that your software has become a snowflake, refactoring becomes impossible. It's too complicated and costly. No one will understand what to change or how to do it, and they become fearful they will break the code. You might as well start thinking about sunsetting this project immediately and begin writing the "Son of (insert your current system name here)" proposal.
Refactoring is a difficult concept to sell to the business. It's a lot like replacing the roof on your house. It doesn't really add any value to the house, but it keeps the water out. So, don't try to sell it to the business, just do it. Build it into your estimation model for any additional work you are about to undertake. You should be able to continuously refactor for about 10% of your project cost. If you stay on top of your code by building it into your culture, you'll be able to do it for less.
How have you dealt with fragile code in your company? Do you talk about refactoring? What are your thoughts? I'd like to hear them.
Gus
No comments:
Post a Comment