Refactoring Efforts: Part 2 - the Evaluation
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Introduction
After a much needed (and frankly job-related) absence, I have the opportunity to continue what was a rather large subject. The thesis of my last article was that various areas of life—in the U.S. in particular—are constantly undergoing a cycle of "create and consolidate." It seems as soon as someone or some company creates a unique or novel object, process, or software application, there exists a broader entity waiting to consume or subsume that concept. In some cases, this is because the synergy makes sense and the result is a uniquely valuable combination. In other cases, it's a misguided effort or just outright profiteering.
In the first installment of this series, I put forth some basic criteria to consider before attempting a combination (or refactoring). These were loosely termed context, customer acceptance, complexity, and scale. Context involved the assertion that combinations could be well-advised in some circumstances but not others. Customer acceptance provided a reminder that many different types of people must believe in the idea for it to be a good idea. Complexity put forward a justification for a cost/benefit analysis (CBA) to fully assess validity—in other words, "Yes, it can be done, but is it worth the effort?" The final criteria of scale is the firmly held belief that corporations, government programs, even screwdrivers can simply be too big. With these criteria in mind, I would like to illustrate some real examples of refactoring.