DaedTech

Stories about Software

By

The Most Commonly Reinvented Wheels in Software

Editorial note: I originally wrote this post for the Telerik blog.  You can check out the original here, at their site.  While you’re there, take a look at their developer tools and controls offerings — they’re quite extensive.

If you ever want to set off a heated argument among software developers, you could do worse than to ask about “build vs buy.”  This one touches the third rail to such an extent that it has many colloquial names attached to it.

If you want to see this debate in action, plenty of venues exist.  Developers may accuse one another of reinventing the wheel, only to hear that some wheels need reinventing for various reasons.  Opponents of the practice have even described it as a syndrome, called “not invented here syndrome.”  But I have also seen proponents turn the tables and call out “not ever invented here syndrome” to describe software shops that awkwardly buy when building makes more sense.

Suffice it to say opinions abound and no clear consensus exists.  The highly context-specific nature of a given example also muddies the waters.  What makes sense for your team in your situation may not apply to another team.

I’ve offered thoughts on navigating this issue in another post.  Today, I’d like to avoid controversy.  I won’t weigh in on whether reinventing wheels makes sense because it deepens your knowledge or whether it wastes time and money.  Instead, I’m just going to catalog the most frequent examples I see of wheel reinvention.  As a consultant that specializes in assessing codebases and application portfolios, I see a lot of code.  This gives me a bird’s eye view of what shops love to write themselves.

Read More

By

Rewrite or Refactor?

Editorial Note: I originally wrote this post for the NDepend blog.  You can find the original here, at their site.  While you’re there, take a look at some of the other posts and announcements.  

I’ve trod this path before in various incarnations, and I’ll do it again today.  After all, I can think of few topics in software development that draw as much debate as this one.  “We’ve got this app, and we want to know if we should refactor it or rewrite it.”

For what it’s worth, I answer this question for a living.  And I don’t mean that in the general sense that anyone in software must ponder the question.  I mean that CIOs, dev managers and boards of directors literally pay me to help them figure out whether to rewrite, retire, refactor, or rework an application.  I go in, gather evidence, mine the data and state my case about the recommended fate for the app.

ProjectManager

Because of this vocation and because of my writing, people often ask my opinion on this topic.  Today, I yet again answer such a question.  “How do I know when to rewrite an app instead of just refactoring it?”  I’ll answer.  Sort of.  But, before I do, let’s briefly revisit some of my past opinions.

Getting the Terminology Right

Right now, you’re envisioning a binary decision about the fate of an application.  It’s old, tired, clunky and perhaps embarrassing.  Should you scrap it, write it off, and start over?  Or, should you power through, molding it into something more clean, modern, and adaptable.  Fine.  But, let’s first consider that the latter option does not constitute a “refactoring.”

A while back, I wrote a post called “Refactoring is a Development Technique, Not a Project.”  You can read the argument in its entirety, but I’ll summarize briefly here.  To “refactor” code is to restructure it without altering external behavior.  For instance, to take a large method and extract some of its code into another method.  But when you use “refactor” as an alternative to “rewrite,” you mean something else.

Let’s say that you have some kind of creaky old Webforms application with giant hunks of gnarly code and logic binding the GUI right to the database.  Worse yet, you’ve taken a dependency on some defunct payment processing library that prevents you from updating beyond .NET 2.0.  When you look at this and say, “should I refactor or rewrite,” you’re not saying “should I move code around inside this application or rewrite it?”  Rather, you’re saying, “should I give this thing a face lift or rewrite it?”

So let’s chase some precision in terms here.  Refactoring happens on an ongoing and relatively minor basis.  If you undertake something that constitutes a project, you’re changing the software.  You’re altering the way it interacts with the database, swapping out a dependency, updating your code to a new version of the framework, etc.  So from here forward, let’s call that a reworking of the application.

Read More