injecting good patterns and OOD into old app
if you have an application that has been in development for 5 years w/o any architectural oversight or concern, how do you go about putting in good design at this point?to them the program "works".and i guess it does, but how do you convince the program owners that "good practices" should be implemented?or do you just let it go till it breaks?i mean, fixes are just programatic.OOD is about how easy it is to update and maintain, so w/o good patterns, aren't you just adding to the burden of maintenance and scalability, etc?you could just throw more and more people at it to keep it "working".anyone face a situation like this on applying designs and good OOD?
[671 byte] By [
arabotha] at [2007-10-2 8:40:08]
http://www.amazon.com/gp/product/0131177052/sr=1-1/qid=1135875759/ref=pd_bbs_1/104-6557574-8787137?%5Fencoding=UTF8
http://www.amazon.com/gp/product/0321213351/ref=pd_bxgy_text_b/104-6557574-8787137?%5Fencoding=UTF8
http://www.amazon.com/gp/product/0201485672/ref=pd_bxgy_text_b/104-6557574-8787137?%5Fencoding=UTF8
http://www.amazon.com/gp/product/0321127420/ref=pd_sim_b_5/104-6557574-8787137?%5Fencoding=UTF8&v=glance&n=283155
yes, all the time.
you'll have a hard time mandating anything without management support.
unless you can make a business case for rewriting code that "works", i think the business will have to weigh that against the opportunity cost of writing something new.
refactoring should be something that can be done 'in place', while the rest of the application goes on. after all, the definition of refactoring is to change the structure of existing code without changing its function.
start with interfaces, layering, and programming by contract. no one should have to read the source code to figure out how a class or method works. if they do, change them until they can.
if you don't have a clean persistence layer, make one. forbid direct access to the database tables, eventually require that all clients go through the data access layer.
likewise, having a clean service layer will help.
be careful with where you place business logic. don't spread it throughout the application, because it can make changes hard to do.
it'll help a great deal if you have a suite of junit tests available that can demonstrate the proper "before" behavior. if the tests all pass before and after your refactoring, you have some confidence that you haven't changed the behavior. start developing that suite while you refactor if you don't have it now.
it's a tough problem to tackle, no doubt. no easy answers here.
%
> anyone face a situation like this on applying designs and good OOD?
Don't take it as an insult, but you must be pretty young in the field to ask the question?:o)
Seriously, yes, this is extremely common, based on my short carreer and on Internet readings.
And you put it well, that you have to convince the "program owners" (CTO, marketing manager, program manager) that good practices will be profitable in the long run.
I hope others will comment, as to how to actually estimate some figures to feed your PO with.
As an example, I used to work in a shop where the development environment did not allow hot deployment on theapplication server.
I annoyed a manager who didn't care, until I showed him that the startup time (a few minutes) multiplied by the number of restart per day (a dozen) multiplied by the number of developers (>100) was amounting to a man-week per week. He bought it and the feature was implemented in 2 days.
That was an easy one; do other have success stories of convincing management to buy a technical refactoring/re-architecturing?
I'm short on time tonight, but I'll try to come back with a few recipes to identify areas of high maintenance cost (in essence, build statistics on usage of version control system).
I would give you, additionally, a formal advice : I trust you that your request is backed by a solid understanding on how good design and architecture will improve performance, ease maintenance, etc... But be careful not to give the impression that you want good practices for the sake of purity or beauty :
Your wording such as "application [designed] w/o any architectural
oversight or concern" or "good practices should be implemented" will sound suspicious to a manager, and even to your peers.
I don't know your specific situation, but you seem to be angry at the program owners, who wouldn't care for for the mess. They probably do care, indeed, as sone as it costs them : it's just that budget/time/priorities require arbitration, and arbitration, in a well-managed shop, will always be to the more profitable way. Until the PO is given evidences that maintenable code will improve profitability, he has no reason to buy the rearchitecturing.
Lastly, do not forget the hidden costs of rearchitecturing.
At the details level, Refactorings and Patterns may be familiar to you but not to all your colleagues.
And at a higher level, a different architecture may require a steep lurning curve, such as repackaging, especially in a non-agile dev team ("hell where has MY class gone?"). It may even require to update the development environment, for which developers themselves tend to be very conservative...
> I'm short on time tonight, but I'll try to come back
> with a few recipes to identify areas of high
> maintenance cost (in essence, build statistics on
> usage of version control system).
OK as promised:
One of my colleagues indeed used the following approach on a common work:
- we had conventions to put one of 2 different keywords in check-in comments, to distinguish bug fixes from new features (e.g. 'FIX' vs 'RFE').
- from that he could analyze the CMS logs and determine the number of FIX/RFE modifications per file, package,...
(N.B.: elaborate CMS tools probably support this off the shelf. In my case even the Clearcase senior that did my training didn't know how to build such stats).
Intuitively (I didn't pour on this more thoroughly), we derived the following interpretation:
- a source file/package with LOTS of check-ins is a sensible point in the software. It may become a bottleneck (concurrent modifications will require merging, more thought, more testing, etc...).
- In particular the number of FIX is more than linear on the size of the individual souce file.
- an item with more FIX than RFE modifications is probably too complex to maintain (every change introduces regressions).
- the average number of file involved per FIX/RFE gives an indication of the degree of coupling (but for an RFE that has to be ponderated by the complexity of the corresponding feature, which we never did).
- we didn't do this, but I'm pretty sure that the FIX/RFE rate gives an indication of the fragility (likeliness of bug per enhancement). We didn't measure it but I had the feeling that it increased (I mean, the software was more an more complex to evolve)
- one of the things I've never had the power to undertake is building statistics to distinguish regressions from new bugs. But that requires tracking, for each bug, not only the technical root cause, but the change (RFE or other FIX) that introduced it. Few developers I have met do this, so maybe it doesn't pay back.
Additonally, though we haven't tried to dig this path, figures such as the overall check-in rate can give an indication of the product's health (a check-in rate that stalls means the product does not evolve, or, and I've seen it, that developers are reluctant to deliver the smallest change for fear it might break something).
Despite the limitations and assumptions of these punctual studies (once per year), we did use the information to recommand redesign of certain potions of the software. I didn't stay long enough in this shop to measure the return on investment, but at least managers bought the redesigns, and the very fuzzy indicator of developer's "quality of life" seemed to improve in the impacted teams.
Back to your question :
once you have such indicators, you could show the program owners that new features are increasingly complex to build, that regression bugs are increasingly likely, and that the overall evolution rate is decreasing.
If you have more than one points in time, you can estimate a trend and identify a rough date when the yearly software maintenance cost will cost more than the yearly software income. That kind of information will strike PO minds more than well-intended stances on "good design".
OK, I ackowledge that the long and naive discussion is based on opinions more than facts so I really wish others could comment :
how do you estimate the cost of bad design, the cost of redesign, and the benefit of good design?
J.
