REFACTOR MAN

If you work in technology you have almost certainly met the REFACTOR man? There is one on every project with more than four team members.

You will recognize this guy as he runs around the office yelling "Refactor!!" It does not matter the problem, the answer is "refactor". (Note: as I type this entry the spell checker is indicating a misspelled word for refactor)

After several years of dealing with this omnipresent band of boobs I have decided to offer up a definition of refactor. My definition is as valid as any other since refactor is not actually an accepted word in the English language as defined by Webster (http://www.merriam-webster.com/dictionary/refactor), so here goes...

To Refactor is to take any piece of functional software and spend twice the time it took to originally write the software rewriting the software to conform to some "Pattern" (more on those in another entry). In and of itself this is not necessarily a bad thing, unfortunately the process of refactoring almost always costs more than it cost to build the damn software to start with when all the cost of testing and retrofit are considered. Let's not forget that in some extreme cases of refactoring functionality may change, or even disappear.

These small matters represent no consequence to REFACTOR MAN; the user obviously did not know what they were doing when they wrote requirements that did not conform to the patterns. Users are so stupid. The problem with every system can almost always be traced to some user doing something stupid like trying to use the system.

I would like to propose another potential source of the problem. Maybe REFACTOR MAN did not fully understand the problem he was trying to solve and went of half cocked and (predictably) came up with a half ass solution. Perhaps REFACTOR MAN was not quite truthful on his resume when he landed the job of senior developer or system architect and did not actually have the experience to know the best way to solve the problem. Maybe, just maybe, REFACTOR MAN should have read the entire Gang of Four book to understand the patterns before he started stealing quips and bits from Fowler’s bible on refactoring.

So the next time you are in a meeting with REFACTOR MAN trying to solve a problem in system B that has some minor dependence on system A and, true to form, he stands up and proudly pontificates the answer is to completely refactor system A. You should immediately rise from your seat, slap the taste out of his mouth, and calmly continue the meeting. Don’t hesitate, and for God’s sake don’t let him get to the white board. Once REFACTOR MAN starts to draw a sequence diagram his powers grow ten fold. If you don’t catch him before he gets to the board just leave the meeting, wait three to five minutes, and return. That is about the most time your run of the mill REFACTOR MAN can string together lucid and coherent thoughts in support of his position. If your REFACTOR MAN is particularly skilled in the black art of Ninja mind control tricks you may have to wait seven minutes.

It is generally best to just end the meeting at this point since the attendees will be slightly dazed from the complete vacuum of common sense created by the refactor rant. Don’t worry this will wear off after a few hours. After the meeting tell your supervisor you need a raise as you just saved the company twice the original cost of system A.