|
|
|
           
|
 |
|
Ideas – Refactored One of the many problems in need of new ideas is how to enhance old software to make it young, feature-current, and maintainable once again. One of these processes, Refactoring, sounds like an answer to the challenges of old software. Old software gets hard to work with. As we have covered in the past, the bathtub curve can spell the end of software. Simply put, as software approaches its seventh release, it is too full of patches and workarounds to be safely revised, and its architecture is too stretched trying to do things it was not designed for to be saved. A rewrite is needed. The real risk is that during revisions near the end of life, software can end up broken in pieces on the floor and may never come back together. Short of that point in time, refactoring may be an answer. The basics of refactoring include making small, function preserving, and structured transformations of the code base to correct errors, omissions, and perhaps just inexperienced or sloppy work of the past. As businesses try to delay the inevitable rewrite, the engineers will get increasingly grumpy about having to work with such low-quality code, marketing will complain about the cost and unpredictability of schedules, and management will complain about the high percentage of the development budget being spent on ‘maintenance’ and not on new things (see the technology trap). But what Refactoring promises is tempting – a solution in an area where there is a lot of pain. It still has risks and needs extensive testing after changes are made, is difficult to quantify individual changes on an ROI basis and needs experienced software engineers – people who know how to be very careful. Nevertheless, it is around. So here are a few links to help you get acquainted: First, a definition from Wikipedia: A web site for refactoring with links to
resources and case histories: A book on the subject with explanations,
approaches, and cases: Project leaders swim carefully in the waters of projects that change code but don’t add features or function; that don’t add commercial value. These projects are infested with sharks including ROI, predictability, test coverage, team resource management, and extensive peer reviews. All told, if you are early in a project’s life and the business needs this, tread carefully. If you’re at the end of the life of the software, then a rewrite might be a better use of the team… a better business investment.
|
|
| Copyright © 2001- 2007 by Dennis Smith All Rights Reserved |
