- Introduction
- Impact of Refactoring on Everyday Life
- Impact of Refactoring in the Workplace
- Impact of Refactoring on Information Systems
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Impact of Refactoring on Everyday Life
Things have long been combined—usually for reasons of saving space, weight, expense, and so on—into convenient groups. Rarely do the combinations result in anything but a shadow of the former items, but in a portable version they often give an acceptable level of function. The trick is to define those situations in which the benefits of consolidation outweigh the loss of specialization. This is a decision that, thanks to the hype of the web, takes place more frequently and across more boundaries than ever before.
The web has started many experimental companies with untested (if very dedicated and eager) entrants into the world of business and the world of computer programming. Traditional boundaries separating workplace roles and responsibilities have become more fluid than ever before. Titles are created using previously unrelated words. The rationale is often for convenience or cost savings, but the mentality becomes infectious. People are awakened to a freedom not previously experienced.
Sometimes the consequences are very good; at other times decisions lead to confusion and duplication of effort, or, worse, putting someone into a position in which they're not equipped to succeed. The impact continues at work, but first let's examine more tangible scenarios to see whether patterns exist in the world that could help these decisions at work.
Tools are a good first example. Somehow the puny hammer included at the end of the interchangeable screwdriver/hammer keychain never resulted in contractors forgoing their large tool belts in favor of a single key ring of tools. However, for a long time it was a geek price of entry to carry a Leatherman multi-tool. (For those of you in the fitness set, think of the handy trail tool you carry in the tidy-tote around your waist or under your bike seat.)
This leads to a first guideline that we will call context.
Guideline 1: Context
To explore combinations of things, it's wise to first examine how much the performance of any one of the items will be sacrificed to make the combination work. Cell phones combine the communication portability of walkie-talkies with better range but with talk time and audio quality far less than a regular telephone. The market has decided this is an acceptable tradeoff. Unacceptable tradeoffs don't necessarily mean that the idea is bad; it just means that a weighted priority may have to be given to one item over another. For example, if someone could create a screw-on hammerhead that stays attached long enough to finish a whole nail, it might at least reach home improvement grade.
In many cases, pairings exist in nature, but preferences or simple dogmatic rejection of change is an impediment. This will typically result in the product being marginalized until market forces propel it forward (maybe). Two very squeezable examples exist:
The only maker of a squeeze-bottle combination of peanut butter and jelly bills itself as the world's best such combination. It's the only one because, well, some people like me prefer the jelly and peanut butter to arrive separately, not intermingled. But there are enough parents for whom convenience is adequate (and kids who think it's neat) to create a niche market.
Some apparent genius decided to separate epoxy into base and hardener in two separate tubes with a single plunger. No longer the victim of brittle or mushy epoxy joints, I am happy.
This leads to a second axiom—that of customer acceptance.
Guideline 2: Customer Acceptance
Carving out a small section of the market may be sufficient, as in the peanut butter and jelly example. If the investment in production is small enough to support low volume, for many customers it could be just the thing.
Keep in mind that customers come in all varieties, and customer satisfaction applies to the boss just as much as the supermarket shopper. A manager may be able to reduce bottom-line costs with an idea that reduces head count, but reject the idea because he measures his self-worth by the number of direct reports he has. Similarly, a developer may fight submitting control of class design to a unified base class because of the resulting constriction. Psychology should always play a role in such decisions.