This week's book giveaway is in the OCMJEA forum. We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line! See this thread for details.
Hi Guys I've just taken over an application developed by a 3rd party and would like to refactor it with an eye to simplifying maintenance in the future. However, the PHB has asked for a figure (days) for the work. The number needs to be defensible and I'm looking for an established formula to apply in order to come up with an approximate estimate. Any ideas? Thanks
What's immediately measurable would be the time it would take for you to identify all the individual use cases (functions) of the application and then the time to write all the junit testcases. Can you start with that ? Cheers, Pho
Joined: Feb 12, 2002
Thanks Pho. I'd thought of this but I already know that this isn't going to suffice for the PHB. He's putting budget figures together for the next twelve months and wants an 'accurate' number. I know that he's asking for the impossible and I will be couching the numbers with caveats to that effect but I'm not going to get away with failing to give him a number. What I'm looking for now is some kind of guide that I can use so that it's a little more than "John's opinion". I guess that this could be the time to think of a number & double it ;-> Any further comments most appreciated...
In order to quote for anything, the first thing you need is to find out how you will know when you are finished. It may seem obvious, but I'm astonished by the number of fixed quotes I have seen for essentially "open ended" projects. Quoting in advance for an open ended project is a sure way to fail. Either you, the PHB, or someone else must decide on some "acceptance criteria" for the refactoring work. Then you stand a much better chance of being able to quote for the effort. As for how you decide on acceptance criteria, it really depends on the goals of this round of refactoring. It's vital to realize that refactoring never really finishes, it's just that you sometimes get to a point where you can't work out what to refactor next. Then you can make feature changes to the code, and are ready to look for refactorings again. If you have any particular maintenance work (high-profile faults, important new features etc.) in mind, look at the system in the light of these and consider how you would prefer it to be, to make these changes quick and cheap. If you have any code-metrics tools which show problems in the code, consider phrasing the acceptance criteria in terms of acceptable metrics. If you can, try and set intermediate goals, too. With intermediate goals to provide feedback on progress, you can track how well you are doing, and (hopefully) steer the project to an acceptable conclusion. Once you have set your goals, you are free to choose the best and most efficient path to get there. Refactoring aimlessly, particularly if you haven't got a lot of "gut feeling" for it, can use up a lot of time and credibility. As for how long it will actually take, I don't think we know enough about your project or work environment to offer suggestions. What state is the code in already? What sort of test scaffolding do you have in place? What (if any) refactoring tool support do you have? How many actual hours a day will you get to work on this, and how many will you spend on phone calls, meetings, research, other projects etc. ? How much refactoring experience do you (and your team) have ? Please tell us more ...
I attended XP/Agile Universe in Chicago this past July, and have been refactoring for 1-2 years. One thing I picked up from the conference is that it frequently is extremely difficult to refactor code 'thoroughly' and add adaquate unit-tests that wasn't written with testing in mind in the first place - actually written by way of 'test-first-design'. It might even be impossible! One experienced hand told us to even consider throwing out huge sections of code and rewrite t via test-first-design. Normally this is impossible to justify doing this to working code economically. So it really needs to be done very gradually and incrementally, as part of the work of adding new features. And don't ever think you will ever be able to refactor legacy code to where it will look like 'green-field' code - it will never happen. At best you will only get partway there. I struggled for over a year trying to do this - until people at the conference said I would never get there. Pertaining to your question, refactoring is not a task you can estimate, it is an ongoing process, which should only be done intermingled with necessary enhancements.
Would there be any value in developing a refactoring "checklist"/methodology for the developers that will be maintaining the system to check when they go in for bug fixes/enhancements. What I have done at my company is when I go in for a bug fix/enhancement I have a list of things I need to check(most of which is based on Martin Fowler's book) on code. If the code "smells" funny or some of the items that I have on my checklist come up(ie. using magic numbers instead of constants), I'll refactor it. I've developed my checklist using basically one source, but you might be able to sell them on the idea of a refactoring "framework" based on your experiences. The difference is that you'd be helping to implement a refactoring methodology, instead of only fixing the code and then leaving. Its a hard idea to accept, that although pieces of code may run well, you need to continuously improve it. The old adage, if it ain't broken don't fix it- is very true- but it just depends on what your definition of "broken" is.
Joined: Feb 12, 2002
Hi Guys Thanks for all of your replies. Everyone of them has been useful in helping me to ponder this problem further. Acceptance criteria were always going to be one of my caveats to the figure that I end up quoting. The checklist approach / creation of a framework was originally outside of what I was considering here but I think that I'll include it now. To some extent calling this a refactoring project is a misnomer. More accurately it's a clean-up job but I want to get more from it than 'nice' looking code. It'll also act as a first taste of refactoring for my project team, (I've worked in an XP environment before but never been responsible for leading such a project). I guess that the sensible place to start in compiling the checklist is C3 of "Refactoring". Once I've got this I can estimate how long running through the list is going to take for each source file. Making a few guesses about the amount of work that will result from the investigation should get me nearer to a reasonable number. Then I'll double it ;-p Again, thanks for your replies.