DEV Community: James O'Donnell

When to rewrite, when to refactor

James O'Donnell — Fri, 18 Sep 2020 20:55:45 +0000

What I mean when I say:

Rewriting: Taking the requirements of a given system and coding them in a different language, architecture or paradigm.

Refactoring: Bending code by restructuring it to fit a new paradigm for the sake of maintainability, testability and extensability

Early in my career, every legacy system I came across seemed to be prime for rewriting. Surely all my new tools could produce a better barn than the barn we currently had. Surely it would make a barn that never needed to be refactored or rewritten. I was allowed to chase that road too many times and at too great a cost to consider the constant clamor for "Rewrite it" to be my default.

Here is why.

Lie #1: Rewriting makes integrating new features easier. You can build them in from the ground up.

Answer: If the software has not suffered organic growth, rewriting will end up in the same place as a refactor. Even if the code ends up following a different paradigm, it still has to meet the original requirements.

Lie #2: Refactoring is hard. It is hard enough to make it not worth it.

Answer: It can be, but it can also reveal if a rewrite is actually needed. It can expose systemic problems that you can't see otherwise.

Lie #3: Newer technology makes code cleaner and easier to maintain.

Answer: Javascript, C#, Java, Python, Ruby, and Go all suffer from the same problem; they are languages. They all have encumbrances that try and hide the hard parts of computers away from the poets and wizards writing code. Those encumbrances are prone to obsolescence. I wrote quite a bit of C# code for .Net 2 & 3. None of that code would run today. Windows has changed. I wrote a Javascript booking engine for a travel site in 2001. It would not even render today. I could easily take that same code, however, and update it to run in any of the latest stacks. The answer of rewriting versus refactoring can be driven home on this point. I already paid the price for those features once. Why would I pay it again?

The idea of software maintenance should expand beyond bug fixes or incremental feature adds. The roads we walk to a future state are shifting sands. We have to keep on top of that technology and build that price into our code.

Lie #4: It is cheaper to rewrite it.

Answer: Maybe. If the stack is based on an ancient technology that cannot be modernized and the price per developer is more than the initial cost of the product, it might be cheaper. If it isn't boxed into a dead vendor or dead language, this argument becomes much more false.

In general, unless the product name is the only thing being reused, I evaluate this based on the number of functional features in the code base vs what is being asked for. If I already have the code, why would I pay for a rewrite?

Recognizing a trend vs. a lasting truth

James O'Donnell — Fri, 03 Nov 2017 20:21:52 +0000

I had the fortune (or misfortune) to have been doused in JavaScript at a very early part of my career. No matter how many "better" platforms or technologies came along, JavaScript always seemed to worm its way back into my life. In '96-'01, it was simple demand that formed my skills. Now with Node, Angular, React etc, the punishment of those early years has paid off. JavaScript has become a lasting truth. For good or ill, JavaScript won't be going away. It will live on.

There are other languages that I learned during that time too, though. Stuff like Perl, ActionScript, VBScript and others. I guess you can still use some of them, but they have fallen out of favor. I would give away a puppy to have the brain-space and time that those took from me.

My question; do you have a crystal ball? How can you tell what you should be investing your time to learn? Have you only been lucky?

Code Camp Curriculum

James O'Donnell — Thu, 02 Nov 2017 15:51:04 +0000

I am organizing a code camp for middle-school aged kids and need some ideas. We are giving the kids a Raspberry Pi to take home at the end of the camp and I want to foster the idea that they can do more than read instructions and repeat what is written down. I am trying to spark something in them. To that point, I have been limiting my research to JavaScript and Python.

There are several great starter projects on AdaFruit, etc. but they are single session projects. I am guessing I could staple a few of those together for a five day class, but I would rather have a cohesive curriculum.

Has anyone else done something like this? Am I failing at Google-jitsu?

Music and coding

James O'Donnell — Wed, 01 Nov 2017 19:09:03 +0000

I have used music as my productivity driver for a long time. More than coffee, I need the right soundtrack for a project. Bowie is for pattern-based stuff, Beirut is for boilerplate, Chemical Brothers is for inventing. So what drives you? Does music reach you the way it reaches me?

This pic was taken at 30k feet over Colorado, flying between two massive super-cells.