begin quoting Tracy Reed as of Fri, Oct 31, 2008 at 01:21:23PM -0700: > I wish to do my best to attempt to remove my own personal biases from > this decision so let me throw something out there for comment: > > I have inherited a project using a webmin v1.310 based control panel > which has been extensively hacked up to be the control panel for an > appliance as well as a couple coders to work on it. A massive amount > of time and money has been poured into maintaining it over the last > few years which management will be very reluctant to walk away > from. However, due to lack of adherence to best practices it has > acquired a lot of what I call "technical debt". > > Issues with this codebase: > [chop] > 2. It has duplication of files within the codebase. For example there are; > ./wizard/lvm-lib.pl > ./lvm2/lvm-lib.pl > > which are mostly the same file except the one in lvm2 has an extra 15k > of code added to it.
Are they compatible? Can you use only the one in lvm2? This sort of duplication can often be eliminated with minimal effort. > 3. Duplication of functions cut and pasted between various other modules. Likewise. Refactor refactor refactor. > 4. No template language so html and code is intermingled everywhere. And again... refactor. Pick a corner of the code and start there. You may want to pick up a book on refactoring techniques and philosophy. > 5. There is CVS involved but it's a mess and full of redundant and > nonused files, HEAD and REL_CUR and constantly being inverted, there > is no single version really tagged as a release they just release to > production whatever was in HEAD when they built the box, and who knows > what else. Establish sane policies. Don't put too much effort in cleaning up the past. [snip] > 7. This codebase has support for lots of different operating systems > which is unnecessary for our project and adds a lot of > complication. It might even be the reason for the above foreign > functions. Can you isolate all the os-specific stuff to one module, and keep it there? Or better yet, rewrite it in a portable way so that it can work the same on any platform, without change? > 8. These are more stylistic issues I guess but it looks like a cgi app > from 1998. It uses frames, often requires sideways scrolling, no > header/footer includes (top frame is like the header), etc. Hey, CSS provides tables for layout now. > And that's probably just the beginning. So there is a huge amount of > cleanup to be done to get this into any sort of decent shape. > > Might it be better to start over? Maybe. If it's mostly working now, probably not. > How does one judge when to make the case for starting over vs. just > sucking it up and incrementally improving what we've got? Fundamental correctness problems. If the code just stinks *but* it basically does the right thing, a rewrite will probably make things worse before it makes it better. I've engaged in and seen rewrites go both ways. I've seen the result end up with an equivalent product that was no better (only different) than the original project, and I've seen the rewrite produce something that was smaller, faster, better organized, more stable, more flexible, and better documented. > Making big changes to this codebase could easily cause collateral > damage as there s no test suite or anything. It seems that as time > goes on this codebase is requiring more and more resources to keep > going and has a very spotty history of reliability as it is. Can you first build up a test suite? If you have a working test suite, you can (a) do a much better job fixing bugs without breaking existing code, and (b) can get a quantatitive measure of how well a rewrite is doing. > I would like to get them out of the business of having to maintain so > much code to concentrate on what actually makes them money. > > The big theme of my involvement here so far has been to push as much > maintenance work upstream as possible and do as little custom as > possible except that which very specifically adds value for us and so > far that is working out well. Sounds like a reasonable plan. > If we moved to a different community maintained codebase more aligned > with what we really want this thing to do to implement the needed > functionality and it happened to be object oriented we could > inherit/override aspects of the original code we don't like with our > own code. Our much smaller amount of code could be kept and maintained > separately while still being able to drop in newer versions of the > code as they came from upstream and fix up whatever (hopefully minimal > but who knows) API incompatibilities occurred. Does this sort of thing > actually work in practice? Depends on the discipline of the upstream folks. If they're good about not breaking stuff, yes, it can work. If they willy-nilly change APIs, remove or move functionality, then it sucks, and you end up locking to a *particular* version of the tools. I've seen it go both ways. And sometimes folks knee-jerk when establishing policy -- they get burned by "upstream" changing crap for no good reason, so they just get in the habit of locking down everything to a single listed version, no upgrades allowed without prior approval (The new version fixes a critical bug? Okay, we'll expedite that through the process -- it'll only take six months for approval. If it's approved.) etc. etc. If you're going to switch communities, understand the new community before you jump. > However this would require learning a new base framework and rewriting > some of our custom modules which the new framework does not already > provide. It would also incur some political risk in telling management > that they are trying to polish a turd with the current codebase and > ask them to invest even more. I just want to do what is best for the > client and therefore my career. > > Comments? Start with documentation and testing. Determine module boundaries. Get a handle on coupling in the system. It may be that you can carve off the key functionality into fairly independent modules, and at that point if you still think you need to jump ship, you can point out that most of the code won't change. Then again, the code might not look so horrible by then either. -- I should write some more tests today. Stewart Stremler -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
