3

Despite Joel's missive that software rewrites are to be avoided under pain of death, it is still fairly common place. A lot of the existing software is good, but here and there, parts of it niggle, so for a while, you continue along your way.

"You can't polish a turd, but you can roll it in glitter"

So you tweak it here and there in a haphazard fashion - tinkering round the edges because you don't want to dig into the innards. Time passes, technical debt, software entropy - you get the picture.

This, until someone suited and booted says: "No more". Perhaps the language has fallen out of vogue, or has been superseeded. Now, which of the following (or mix of) can be used to aid the process? Are there any other methods? What other factors are there?

EDIT: I'm not looking for an ever increasing pick-and-mix list of approaches here - more a cohesive toolkit.

Line by line

If the project isn't too large, you may be able to look at the code line by line to get a feel for what it is doing.

Functional clone (dev view)

As a developer of the previous incarnation, you may have a spin on what the various functions are so you design from there.

Functional clone (user view)

The user (or team of), get together and decide which features are the most important and which can be parked until a later phase or scrapped.

Forensics

3rd party tools are used to extract the module names, method names and data structures.

Path analysis

Code is added (or perhaps existing audit code leveraged) to see which are the most commonly used parts of the program and go from there.

gnat
  • 21,442
  • 29
  • 112
  • 288
Robbie Dee
  • 9,717
  • 2
  • 23
  • 53
  • 2
    recommended reading: **[Why do 'some examples' and 'list of things' questions get closed?](http://meta.programmers.stackexchange.com/a/7538/31260)** – gnat Dec 22 '15 at 09:21
  • 4
    At the end, all what counts is if the rewritten software fulfills still all the requirements. So the "functional clone from users point of view" is always the main goal and the smallest common denominator. How you reach that goal depends heavily on the software, and all the other points you listed are just techniques to analyse if you can avoid a full rewrite and reuse some of the existing code and design. – Doc Brown Dec 22 '15 at 10:21
  • @gnat I've added a few clarifications. I'm certainly not just looking for an ever increasing list or case studies. – Robbie Dee Dec 22 '15 at 12:12
  • 2
    @RobbieDee: though I think the core question is a good one, I would like add an even stronger warning note that the decision for a rewrite should be done with extreme care, and only after reading [this former question about big rewrites](http://programmers.stackexchange.com/questions/6268/when-is-a-big-rewrite-the-answer) in-depth. – Doc Brown Dec 22 '15 at 12:32

2 Answers2

5

Development techniques change and improve all the time, so if you are undertaking a rewrite, it's unlikely that you'll want to simply copy the current code's structure. So I'd suggest you can rule out the Functional clone (dev view), Forensics and Path analysis approaches. These will likely lead to duplication of bad parts of the code, as well as the good.

The other two approaches need to be used in conjunction with each other:

Functional clone (user view) You are having to start from scratch, so by talking to the users up front, you can both:

  • Take the opportunity to find out if all the features in the current app really are required, and whether there's any missing features that they've always wanted.
  • Prioritise the order in which the features will be added and define a Minimum Viable Product, which will form the first release.

Line by line Whilst it's time consuming, examining what the current app does is useful. It helps with requirements capture, as users may be unaware of the fact that behind-the-scenes features exist, or forget that vital piece of functionality that they only use at year-end, for example. This analysis should only be used for requirements capture though, unless some of the code can be re-used in the new version. Avoid line-by-line copying of functionality, especially if switching languages. This leads to non-idiomatic, hard yo maintain, code.

Polishing turds

A, somewhat off-topic (though you mentioned it), closing point, is that the statement, "you can't polish a turd", is untrue. Simply search for "polished coprolite" for examples of such polished fossilised faeces...

Jan Doggen
  • 1,140
  • 4
  • 16
  • 22
David Arno
  • 38,972
  • 9
  • 88
  • 121
2

A rewrite has to offer value to the users. That's a must. If you simply declare that an app is too hard to maintain, there's too much technical debt, et cetera, your sponsors will look at you and ask, "Well who made it that way?" And that's a good question. Why write a check to the same team who screwed it up last time? What's different?

That's where a shift in your thinking might come in handy. It's not simply a rewrite; it's Badass App Version X!

There is no view other than the user view.

And it's not a functional clone. It can't be. It has to be better than that. All the nuisances -- extra clicks, clunky navigation, ugly UI, waiting -- you have to fix them. All the feature requests that would have compromised the original app's design -- you have to demonstrate you understand the users' goals so well that those features integrate perfectly into your new design. That, or demonstrate you now know so much that you understand clearly there is no alternative reality in the multiverse where feature Y could exist in Badass App Version X.

Regarding Functional clone (dev view) and Forensics, do yourself a favor and reconsider absolutely every name and relationship. Build improved models based on what you've learned. Don't copy anything until it's been vetted by your extremely thoughtful and deep-thinking team.

Finally, we haven't nailed down what "medium-large" application means. I'm guessing there are opportunities for incremental redesign versus the big bang approach. Are there services? If so, maybe this is a good time to entertain a microservice approach. Build your first microservice using your new technology. While you're at it, pull that business logic out of the UI where the new service is consumed!

Is the UI delivered in the browser? If so, you can do all sorts of interesting things with subdomains, proxies, and virtual directories to allow you to rewrite portions of the UI in a new technology. Sure, it's tricky. You can't have User Admin looking all Bootstrappy while Mail Merge is a gunmetal grey enterprise nightmare. Your UX person may have to bite their tongue until the conversion is complete.

Interested in new data technology? Identify some small portion of the data model that would work well in MongoDB or Stardog or Big Table.

Layer in distributed caching.

You get the idea.

The advantages to this approach are legion:

  • You can verify your assumptions about a rewrite were correct. If it's still a mess, maybe call it off before you spend all your company's money.
  • Demonstrate concrete progress to your sponsors.
  • Distribute risk across time versus saving it all for one terrifying rollout.
  • Learn as you go. It's easier to adjust for the next piece of development versus doing yet another rewrite.
  • Breaking off chunks forces you to think about modular design.
Scant Roger
  • 9,038
  • 2
  • 29
  • 47