Don’t Refactor and Enhance at the Same Time

Last night at my "Introduction to Refactoring" presentation, I received a bunch of blank stares the first few times I said that you aren’t supposed to refactor and enhance at the same time. Eventually, it dawned on me that I was being imprecise in my definition of the word "enhance." After all, refactoring is itself a form of enhancement -- you are improving the design when you refactor. So, what I meant by "enhance" is adding functionality from the user’s (customer’s) point of view. I don’t know where I picked up that terminology. Maybe it was a culture thing where I’ve been working. Do other people use the term "enhance" that way?

Anyway, the bottom line is you aren't truly doing refactoring unless

1. you isolate the refactoring activities from the feature-adding activities,
2. before you apply a refactoring you have an automated unit test that puts the existing functionality through its paces, and
3. the exact same unit test runs cleanly before and after the refactoring is applied.

Note that it’s okay if the unit test has to be tweaked to conform to new method signatures and whatnot, but you can’t change anything that has to do with what the unit test is trying to prove.

The Myth of the 100-Year CD-ROM

Think your CD backups are trustworthy? Think again. According to an article on rense.com, some CDR's don't even last 2 years! What I can't figure out is if that means 2 years from the time it's burned, or from the time it's manufactured? I'm guessing the latter. How fresh is your supply of blank CDs?

Getting Hired

My friends who are about to graduate from the U.C. Irvine School of Information and Computer Science -- and anyone else looking for a programming job -- should check out Arjun Ram's blog. He has some great advice for software engineers in the job market, having recently changed jobs himself.

CandidateMap.com

As we move closer to the 2004 presidential election, it's great to see web sites like CandidateMap.com popping up. This one is an archive of quotes from the candidates sorted by topic. For example, you can pick from 30 topics (e.g. Taxes, Drugs, Environment, Sci/Tech & Space), and then read one relavent quote from each candidate. If you haven't yet formed any opinions, this looks like a great way to get started.

"Intro to Refactoring" on Tuesday, April 27

I will be speaking on Tuesday, April 27 at 7pm in the city of Orange on the topic of refactoring. This will be at a meeting of the Orange County Delphi Users Group, although the topic has nothing to do with Delphi, per se. OCDUG meetings are free and open to the public.

If you have heard the term "refactoring" bandied about, but you're confused as to exactly what it means, you are not alone. It doesn't help that people tend to misuse it all of the time. This introduction will define what refactoring is, what it is not, when you would want to use it and why. In case you are completely in the dark, you'll find an official definition of refactoring below, but don't worry if it doesn't make sense yet. All will be made clear.

This presentation will last a little over 1 hour and include 5 specific step-by-step examples of refactoring. The examples are in Delphi, but
should be easy enough to follow along for non-Delphi programmers as well. A basic understanding of object-oriented programming is assumed (e.g. encapsulation and inheritance). Being able to read a UML class diagram will definitely help as well.

"Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external
behavior. Its heart is a series of small behavior preserving transformations. Each transformation (called a 'refactoring') does little, but a sequence of transformations can produce a significant restructuring. Since each refactoring is small, it's less likely to go wrong. The system is also kept fully working after each small refactoring, reducing the chances that a system can get seriously broken during the restructuring." -- From www.refactoring.com

The OCDUG meetings are held at Red Brick Software, 1301 East Lincoln Avenue, Orange, CA 92865. [Directions]

User Interfaces for Infrequent Tasks

Paraphrasing an article by Barbara Nelson of Pragmatic Marketing, good software may very well be complex, but that complexity needs to be hidden from the user as much as possible. Nelson cites Intuit’s Quicken as a prime example. "They learned what regular people needed by spending time in people's homes, watching how they managed their home finances. Quicken was the first finance package to use the checkbook metaphor, something regular people already understood. Quicken was hugely successful, and even with dozens of competitors, managed to gain 75% market-share because it was easier to use. It was the first product to take a customer-oriented view instead of a data-centric view."

One way to hide complexity is through a guided UI (a.k.a. a wizard or an interview). A common misconception is that a wizard makes a good UI for novices, when in fact they are more properly employed to address infrequent tasks, and should have nothing to do with whether or not the user is a novice. Novices aren't novices for very long (when performing a frequent task). Writing a guided UI for a frequent task is bad, because it eventually bogs the user down. On the other hand, a guided UI is perfect for an infrequent task, especially a complicated, critical, or finicky one, no matter whether the user is generally regarded as a novice, intermediate, or advanced. You might say that when it comes to infrequent tasks, every user is always a novice.

Outsourcing Battle is a Red Herring

On Firday, Slashdot cited an article entitled "How India is Saving Capitalism" that sparked yet another argument pitting capitalism against patriotism. This kind of battle over outsourcing is a red herring. Executives who outsource to save money are failing to see the big picture, and anyone who chooses to fight on that battleground is wasting his time and contributes nothing towards "winning the war."

These executives keep asking the wrong question, "How can I continue to develop the same old crappy software, but do it cheaper?" They ought to be asking, "How can I develop better software?" "How can I develop it faster?" "How can I make it last longer and be more useful?" By improving the quality of their software it'll be more desirable. It'll draw more customers and can demand higher prices. Answering these questions can lead to a 100-fold improvement on the ROI versus any kind of cost-saving measure.

As an added bonus, better software is, well, better. If you want to talk about morality, let's talk about how much better our society will be when the software we use provides more intuitive user interfaces, adapts more easily to our needs, offers increased security, and performs faster.

The sad part is that the answers to these questions are right in front of our faces. All we have to do is open our eyes. The 'Net is a free, all-you-can eat buffet of best practices, high performance/high security open source frameworks, feature rich open source tools, design pattern catalogs, refactoring catalogs, ... you name it.

If you really want to keep the programming jobs at home, then quit sniveling and do something to make yourself and your fellow programmers more valuable. Pick one thing and explore it. Read up on a management methodology like XP, RUP, or Scrum. Or, become familiar with a tool like Eclipse. Or, try out the unit-testing framework that goes with your language of choice. Or, otherwise avail yourself of the wisdom of luminaries such as the Three Amigos (UML), the Gang of Four (Design Patterns), Martin Fowler (Refactoring), and Steven McConnell (Code Complete). Apply what you learn and pass it on. It's as simple as that. (Not easy, but simple.)