The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

It seems like there is always a better way to design/program som

What do you do when what you have been working on works very well but you run across even better/cleaner ways to do what you did? Do you refactor, or do you leave the code alone because it works?
Tuesday, December 20, 2005
I suppose it depends on the purpose of the code. If that piece of code is meant to be extentable and the current system doesn't allow for that easily then I would refactor it to a better solution. But if the code probably won't get changed for a while and the solution is adequate and performance is ok I would leave it.

Time is another factor too, but that depends on your project shedule and release milestones.

There will always be better ways of doing something so you need to measure how much better this other way is and see what you will gain from it.

Just my 2 pence worth :-)

Steve Haunts Send private email
Tuesday, December 20, 2005
Two laws of programming:

1. You can always shorten your program by at least one line of code.
2. Every program has at least one bug.

So... Every program can be reduced to a single line, that is wrong.
Tuesday, December 20, 2005
I leave the code alone if I don't have to touch it. If I need to add to it, I mostly refactor. However, if it's a really vital part of code that is complex, I really think twice before doing it.
Tuesday, December 20, 2005
First you write tests to show it is working. Then, if some day you are working on part of the program that touches the old part that you want to charge, you refactor at that time in preparation for making the other changes.
Art Wilkins
Tuesday, December 20, 2005
Leave the code alone because it works, but make a note to yourself that the NEXT time you have to do this, use the newer approach.  Unless it's a trivial change, of course.

"Code that works" implies it's gone through some time of use, which implies that it has reached a level of robust-ness that you don't really want to throw away merely for the sake of "Better", whatever "Better" means.

It's important to realize that "good enough" in software means a delivered product that you can get paid for, while "always a better way" means a product still in development that you don't get paid for -- whose schedule continues to extend into the future.

Others have found that optimization only helps in very limited circumstances -- namely once you have a complete solution, and you can measure where the solution spends most of its time, and you can optimize THAT portion. 

Otherwise your 'better way' can be like stacking deck chairs on the Titanic.  Yes, that part works 'better', but is it worth the cost in development time to the application as a whole?
Tuesday, December 20, 2005
AllanL5 has hit it exactly.

The purpose of refactoring is to save you time down the road.  If the code in question is stable and not being modified, make the change down the road.

Document it now so your reasoning is available at that time.    (If it takes longer to document than to do, just do it.)  Next time you add a feature to this code, ask yourself whether the refactoring will make this feature's solution better.  And I intentionally use the very vague word "better" because there's so many different factors involved in that decision.  But I am sure about one thing:

Last Responsible Moment.
Chaz Haws Send private email
Monday, January 02, 2006

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz