Good job. Hard to do a presentation on code. But you did your examples well. Thats key. Also, you had more time than you thought. You seemed stressed about time and squeezing content in. You had your audience another 10 minutes wouldn't have hurt.
Hi Adam, as we discussed afterwards, and based on several queries from several audience members, I think it would be good if you could spend some time / chart(s) on the business case around refactoring. How do you convince management it's a good thing? The business part of it is probably harder than the actual refactoring work. In my experience, refactoring was a huge no-no and NEVER approved unless the customer complained about quality and threatened to leave. It's hard to prove that refactoring makes money and does not add significant risk. If meeting time is a concern, you could consolidate your first few charts that discuss having a library, coding standard, IDE, etc, into 1 chart with a bullet item for each. I thought most of those points were obvious, but based on your experience I guess that's not always the case. Also, the chart near the end where you talk about replacing the frameworks, I agree that it's technically possible, but I don't see anyone taking that risk, and the retest that goes with it. Overall, great presentation!
Excellent talk with the broad phases of refactoring. I agree with another comment already made that some time should be applied to "how to convince management that refactoring is not 'a waste of time'". We know it's good to, but the reasons we as developers want to do not always align with the mentality of the decision makers. We touched on some good points in questions, but it would probably save a bit of time presenting by addressing it in your first few slides..."step 1, convince management of the business benefits of refactoring the code to do the exact same thing it already does." I would love statistics if you ever were able to come across them. I'll send them to you if I find them.
Some of your experience on how long each phase has taken in the projects you have refactored, I think, would be helpful too. Every project is different, but do you dedicate sprint after sprint to refactoring. Do you make your own time refactor because management doesn't want to waste the time. How long has it taken to refactoring a whole project while appeasing the needs of the business.
But really, you hit every point that was expected of the talk. These are just nice to haves to maybe save some question time.
I would love to hear this talk again and would recommend it to a person who needs the basics on how to approach the phases of refactoring legacy code.
Comments
Comments are closed.
Good job. Hard to do a presentation on code. But you did your examples well. Thats key. Also, you had more time than you thought. You seemed stressed about time and squeezing content in. You had your audience another 10 minutes wouldn't have hurt.
shame it wasn't a longer session with plenty of code examples. It was great though given the time constraints.
Hi Adam, as we discussed afterwards, and based on several queries from several audience members, I think it would be good if you could spend some time / chart(s) on the business case around refactoring. How do you convince management it's a good thing? The business part of it is probably harder than the actual refactoring work. In my experience, refactoring was a huge no-no and NEVER approved unless the customer complained about quality and threatened to leave. It's hard to prove that refactoring makes money and does not add significant risk. If meeting time is a concern, you could consolidate your first few charts that discuss having a library, coding standard, IDE, etc, into 1 chart with a bullet item for each. I thought most of those points were obvious, but based on your experience I guess that's not always the case. Also, the chart near the end where you talk about replacing the frameworks, I agree that it's technically possible, but I don't see anyone taking that risk, and the retest that goes with it. Overall, great presentation!
Interesting presentation and great tips on how to deal/refactor legacy applications.
Excellent
Excellent talk with the broad phases of refactoring. I agree with another comment already made that some time should be applied to "how to convince management that refactoring is not 'a waste of time'". We know it's good to, but the reasons we as developers want to do not always align with the mentality of the decision makers. We touched on some good points in questions, but it would probably save a bit of time presenting by addressing it in your first few slides..."step 1, convince management of the business benefits of refactoring the code to do the exact same thing it already does." I would love statistics if you ever were able to come across them. I'll send them to you if I find them.
Some of your experience on how long each phase has taken in the projects you have refactored, I think, would be helpful too. Every project is different, but do you dedicate sprint after sprint to refactoring. Do you make your own time refactor because management doesn't want to waste the time. How long has it taken to refactoring a whole project while appeasing the needs of the business.
But really, you hit every point that was expected of the talk. These are just nice to haves to maybe save some question time.
I would love to hear this talk again and would recommend it to a person who needs the basics on how to approach the phases of refactoring legacy code.
Great talk - step by step, with good examples on how to deal with a problem that every developer or company faces at some point.