Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

The Difference Between Refactoring and Redesign is 10 Minutes

DZone's Guide to

The Difference Between Refactoring and Redesign is 10 Minutes

· DevOps Zone
Free Resource

Download the blueprint that can take a company of any maturity level all the way up to enterprise-scale continuous delivery using a combination of Automic Release Automation, Automic’s 20+ years of business automation experience, and the proven tools and practices the company is already leveraging.

Ten minutes is a lot of time. It is just enough to drown. If you're young it can be enough for something quick, like running a mile. And ten minutes is the difference between refactoring and redesign. Anything that takes longer than ten minutes is not refactoring. That is a redesign.

Based on this I could imply that refactoring is what you can do while holding your breath, but that won’t work. First of all, there are only a few men who can hold their breath for ten minutes, and usually they are not good at programming. On second thought, you need brain power to do programming, and free-diving is not about deep thinking, it's about deep ... sinking.

So now we know that redesign is something like refactoring, but it is longer. Complete refactoring is redesign. What about partial redesign?

Partial redesign is practiced when you can't perform a whole redesign and, therefore, you chop it up. There can be multiple reasons for not being able to perform the whole redesign in a single sprint (besides being old). There may not be enough time. That is a key indicator: if you planned to redesign in a sprint and the plan says that it won't fit, you can be very sure, no matter how badly you estimated, that it will not fit.

When you chop up a redesign into small chunks, you have to ensure that you have working code after each chunk is swallowed. This is also a difference between redesigning and refactoring. When you do a refactor you continuously have working code. (Or not.) You can also do a redesign that way, but sometimes you just decide not to do that since it may be too expensive and require lot of temporary code that is needed only to keep the code alive during the process, and is not needed before or after the redesign. (We're lucky in this respect. When doing open-heart surgery there is no such option.)

So you do a partial redesign. And then comes the experience: If you are successful with the first drop of the partial redesign, it will stick at that point. There will be no further time to continue with the rest of the redesign. Trust me, I am an engineer: It is the way it is going to be. In other words, if the drops do not deliver value individually you're better off not doing them at all.

Making it clean and clear: If there is a scout camp that has to be redesigned and you want to replace the location of the kitchen and the latrine, don't start with the kitchen, because when you stop after the first partial redesign you will have two latrines and no place to eat. And then you will be in deep trouble.

Download the ‘Practical Blueprint to Continuous Delivery’ to learn how Automic Release Automation can help you begin or continue your company’s digital transformation.

Topics:

Published at DZone with permission of Peter Verhas, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}