“Keeping you up to date with everything software engineering!”

Degradation is Natural, But is it Good?

Implementation | November 11, 2004 | 4 comments

You just finished working on the first version of a new method for an object you are responsible for maintaining and you are really happy with your work. You start playing around and testing the method and you find a small mistake here and a small mistake there but after fixing each mistake you are certain that you have squashed the last bug.

The implementation details of your method are still fresh in your mind and it is easy for you to juggle the changes you are making in your head while still making sense of it. Every time you go into your code to fix the next problem by adding a line of code here or there or even removing a line or two of code until the problem is fixed you are not concerned with what the final solution will look like. Once the problem is fixed you sometimes are even to scared to look at the code in fear of braking it (frustration sometimes gets the best of you).

Oh come on… don’t make it sound like I am the only one who has done this before. Everyone of you have done this more times then you probably want to admit.

Due to the constant pressure that project managers put on developers to finish their work quicker then is humanly possible we think we can not afford the time it takes to clean up the code that is already working so that the next time the method needs revising either by you or a coworker everything makes sense. Everyone knows the project was due yesterday… it is only one small change anyways. I will get the opportunity eventually to clean up the code (commonly known as refactoring).

The problem is a couple weeks down the line before you get the chance to go back to your code and clean it up a change request lands on your desk that will require you to make small changes to that method. You still don’t have the time to clean up your code now so you just make the necessary changes, check to see if the method still works, fix the couple bugs you find and then once you declare it working properly move onto the next thing in your ever growing list of things that need to get done before your very unrealistic deadline.

A couple times like this and before you know it the code is not even salvageable. There will come a point where it will be quicker to re-write the method then to make a change and validate that it works… the same goes with every other method and object you maintain. Don’t worry it is not just you, every other member of your team is in the exact same position.

The only difference between any two methods is the rate at which it degrades. The more complex the method, the more change requests that affected it, the quicker it degrades. Before you know it you will have no choice but to start with a fresh code base which means your next version of your application will come out one or two years later then expected which gives a nice window of opportunity for another company to come in and take a nice chunk away from your market share. Oops…

There is a phenomenon called “Broken Windows” that was written about initially in The Atlantic Monthly in March 1982 by James Q. Wilson and George Kelling. The authors where not referring in there article to the popular operating system of the same name but vandalism and cleanliness. The authors use the following example in their article:

Consider a building with a few broken windows. If the windows are not repaired, the tendency is for vandals to break a few more windows. Eventually, they may even break into the building, and if it’s unoccupied, perhaps become squatters or light fires inside.

Or consider a sidewalk. Some litter accumulates. Soon, more litter accumulates. Eventually, people even start leaving bags of trash from take-out restaurants there or breaking into cars.

We realize as software engineers that you wanted your product today and not 3 days from now and we totally understand where you are coming from. But for every action there is a re-action and it is our job to notify you of them so you can make a more informed business decision. Every time you ask us to cut a small corner, remember in the long run the interest on that short cut compounds and will cost much more to fix then if you took care of it right away. In three years from now when we are over a year late on the next version of our project you can’t blame us… that is assuming we notified you of the risk. The time invested in cleaning up continuously through out the whole development cycle would be negligible compared to the time it takes us to start from scratch now because we can’t build upon the present codebase.

Why does your code get “dirty” to begin with? When you build a house you don’t just randomly put up a bunch of 2x4’s wherever you want and then later on come back and fix the placement of them. Well… at least I hope you don’t. I think we can’t compare software development to any other profession out there. We are still at a point where whatever we are building is still experimental. We don’t have a fixed set of standard components to work with like when you build a house. We might not even ever get to the point where software development is not experimental. Hence after working out the solution to a problem we have to clean up our answer. Which really does not take us much time to do and benefits us in many ways:

• helps us come up with a simpler solution to the problem;
• allows us to better understand the solution;
• makes it easier and quicker for us or someone else to modify the code later;
• drastically increases the longevity of the code;
• reduce the amount of bugs;
• increase the user experience.

Now how can the quality of the code increase the users experience other then the user encountering less bugs. Do you think that the messy code is only skin deep? What you do in your code will reflect what the users see and will reduce their experience I guarantee you. The elegance of your solution is visible in the user interface. If a piece of code was just added like a patch job the user interface will most likely be done in the same way.

Executive Summary: make refactoring a part of your personal process. Get to the point where you don’t even realize you are doing it and it becomes a reflex.

Now the my question to you is how would you encourage refactoring? The way I would go about it is through creating an atmosphere at work where people commend coworkers for clean code and create a medium where people can share elegant solutions to problems with others. If create an atmosphere at work where quality comes first and the timeline secondary I truly believe the percentage of successful projects will increase.

What do you think? Has refactoring become secondary to you? How would you encourage your employees/coworkers to continuously refactor their code?

Related Links:

• Wikipedia: Fixing Broken Windows
• The Importance of Fixing “Broken Windows” in Your Code

Help Support Us By Visiting Our Sponsor

10% of our revenue from these ads go towards scholarships!

Comments

November 11, 2004 11:09 PM | Louis-Philippe Huberdeau commented:

My trick is to keep things simple. If a method makes over 10 lines, I start asking myself questions about it’s purpose. I can usually split it up into different private methods to perform more specific tasks. By extracting conditions (even simple ones) and procedural sequences, the code gains readability. Since every condition or procedure is named, everything looks very simple. It also makes unit testing a lot easyer.

Of course bugs happen and you actually have “hack” some code to find out what’s going wrong. Sometimes the algorithm is just flawed in the first place because of something unexpected. The patching part to fix the code should not be considered as as a patch but as tests and should be removed. Once you found out what was wrong, the code needs to be cleaned and restructured. You can call this refactoring, but it’s not really the same thing since the code has never been out of development.

If you leave it as a patch, it will have to be refactored. It’s most likely to be left behind because it “just works”. If a problem occurs and you need to get back to it, you will have to understand all those patches, which is a waste of time. If you do it at the same time you fix it, you will save a lot of time. It might only take a few minutes to set everything back in order. I just think it’s a good investment.

As for pressure and dead lines, I’m just going to quote Tom DeMarco in Waltzing with Bears:

[Situation: boss imposes a deadline in 3 months and indicate the loss of profit for each additional month. The developper argues that it’s impossible] “Hans, would that same figure apply to delivery before March thirty-first, as well? If we delivered by the end of February, for example, would that give us an additional hundred-ten-thousand dollars of profit, beyond the revenue stream you projected?” “Yes,” he said. “Definetly.” “And an end-ofJanuary delivery?” I passed on. “Would that make us yet an other one-hundred-ten-thousand-dollar profit?” “Yes,” He said. “If we could put the product in your hands today”—That was February 1996, when the project had just been funded—“would you be collecting that additional hundred-ten-thousand dollars per month for the rest of the year?” “Yes,” he said, a bit less sure of himself now. “Well then, Hans, you obviously started this project much too late. If you’d kicked it off eighteen months ago, we could be shipping now, and all those months of hundred-ten-thousand-dollars’ extra profit…” I let him figure out the implications.

—End of quote—

Software engineering is a very new discipline, and yes, not everything is known so far. Administration does not really understand that there is no magic envolved. Of course, you can throw out a prototype in a matter of days, but a real application takes a whole lot more. As software engineers, our job will be to assure the quality of the development and respect deadlines. If your manager think he can set the deadlines and rule the project, maybe he should ask himself why he hired you. As a project leader, your evaluation should be the one used, no matter what.

If you don’t have the authority to take those decisions, you’re probably just that guy that is there to recieve the blames when things go wrong.

If time is required to make the application more stable and better, it should be taken. Of course, those delays must be included in the original scheddule.

I might be radical, but to continue your example: I wouldn’t let the construction worker use less nails to get the house built faster.

November 12, 2004 03:16 PM | John Kopanas commented:

I love the book Waltzing With Bears. That quote is the reason I bought the book in the first place. I am 2/3 of the way done and I only got the book 2 days ago. I hope to finish it by the end of the weekend and post a review of it.

I agree with everything you said. You make a lot of sense.

November 12, 2004 11:20 PM | Ness commented:

The art of design leads to a simple technical and engineered implimentation. Sounds like a quote doesn’t it. I’m not sure if I’ve read or heard it before.

I would probably liken our profession to that of writers, musicians or other intellectual property creators. Their work is refined and made beautiful over time. The real difference is that their work is not constrained nearly as much as the requirements document does for us.

To get paid you have to create something that someone else wants to solve a problem. To write good software you have to want to sove the problem. The software is simply a byproduct of that problem solving exercise.

February 6, 2005 01:39 PM | Niraj Khanna commented:

I know this comment is being added pretty late, but I was just going through some old articles on the site…this is probably one of my favorites.

For me I ask myself, at what point does refactoring become inefficient or a financial liability? I think it’s often not done because the developers themselves don’t know the globality of the project. They often don’t know that a version 3 is being hammered out between management while they’re working on version 1.5. Because of this they say to themselves “who cares about refactoring…as long as it works.” But let’s assume that the development of a project is an atomic event (i.e. no future versions). Is it really worth it to refactor? Now, I’m not saying code everything in your main, but where do you draw the line. Off the top of my head, I believe this is an exercise the PMs should go through with management as these are the people that understand the project’s longevity at the highest levels. From this understanding, I would think that the PM would be able to set “requirements” for refactoring…sound simple no? What do you guys think?

Post Your Comments

Comments:

Name:

Email Address:
(note: not displayed)

URL:
(note: displayed with comment)