- Consulting / Coaching
- Jeff’s Blog
I’m not overly fond of metaphors. They’re never perfect and are usually abused.
One metaphor for refactoring is dirty dishes. The person who chooses not to clean his dishes as he goes finds himself with a growing, dirty pile of dishes. At some point, presumably, the developer runs out of dishes and can no longer eat.
It’s an adequate metaphor. Refactoring is something you should do constantly, a little bit each time you touch code. Do a meal, wash the dishes for the meal. Your likelihood to throw up your arms in disgust at a huge stack of dishes diminishes.
There are problems, however, with the metaphor. If you don’t refactor your code, it becomes exponentially more difficult to introduce new changes without the possibility of causing problems. Also, companies know they can get away with buying cheap dishes, perhaps even paper or plastic, instead of wasting their time cleaning them. Some companies will throw away expensive china if it’s gotten too dirty. And all companies know that there are a lot of places to leave the dirty dishes lying around.
A Jiffy Lube mechanic, on the other hand, works in a pit of fairly limited size. He changes oil frequently (let’s imagine that a car represents a task on a project). The mechanic can choose to ignore the oil oozings that drip onto the floor. Or, he can take the extra time to clean it up with each oil change.
If the mechanic chooses to ignore the dirty liquid, it begins to build up on the floor. At first, things are a little slippery and a bit of a nuisance. In a short amount of time, perhaps a day or two, the mechanic begins to fall down on the job, taking a bit longer to complete each oil change.
You know where this is going, of course. It gets exponentially worse and worse; soon the mechanic swims against the black filthy tide, and can do one oil change a day if he works hard enough. Finally, the mechanic just drowns, never to change a filter again.
XP or no XP, test-driven development or no test-driven development, programming or something else, all systems have entropy. All systems turn crufty and ultimately become useless. The promise of XP is to allow you to sustain that system for a longer period of time before the costs become too high. This is the hope for any system. Constant, hardcore refactoring at the micro level is essential for this to happen. Don’t let the code drown you!
Yard sales can be a treasure trove for used books. If you like carbon-copy suspense or trashy romance novels, you’ll find plenty for sale at fifty cents or even a quarter apiece. Occasionally I’ll come across some good literature (this weekend: The Fountainhead) or computer books.
This past weekend a beat-up hardback, Herbert’s Homework by Hazel Wilson, caught my eye. I had read the book while in early grade school and remembered it well. In fact, I had only remembered the story but not the title, character’s name, or author. Upon spotting the book, I immediately recognized all three.
(It’s interesting how your mind stores things that you later have a tough time retrieving. And then something presents you with a reminder that jogs the details out of your memory. The experience reminds me of saving a document from Microsoft Word, or Excel, or whatever, and then trying to remember where you saved it a few weeks later.)
Herbert’s Homework was interesting to me because I remember that the author had been a bit prescient. The basic plot was that Herbert was a lazy 7th grade punk who did whatever he could to get out of homework. His uncle sent him a gift to help out. He call it a “portable electronic brain.” The brain looked a lot like a clunky television set.
The brain provided answers to encyclopedic questions, such as the average rainfall in South America. It was able to do math quite well. What it failed at were things for which it didn’t have enough information, such as how Herbert had enjoyed his summer vacation. When presented with this sort of challenge, the brain sat there with a blank screen.
Oddly, the author gave the brain the ability to juggle (poorly) balls above a steel rod. Otherwise, the portable electronic brain was the equivalent of a modern PC. Seemingly smart, but truly stupid until someone properly programmed it.
The book was written in 1960. Unfortunately the author presented few additional details or insights into the portable brain, which breaks down when Herbert tasks it a bit too hard. Worse, the manufacturer goes out of business, so Herbert can’t get it fixed.
I’m curious as to what other visions for the personal computing future looked like at this time. I thought it was insightful for the author to implicitly express the limitations of computing.
I loved all the Herbert books as a kid, and now have repurchased them online so that my son, too can enjoy his antics and adventures.
# posted by Anonymous Aneil Mishra : 3/07/2006 03:53:00 PM
I used to enjoy the Herbert books too. Fond memories.
# posted by Anonymous Anonymous : 12/02/2007 05:00:00 PM
The architect Christopher Alexander wrote a handful of books in the late 1970s on architecture. These books, among them The Timeless Way of Building and A Pattern Language, have a very spiritual and poetic quality to them. Alexander strived for a classic sense of building, something that he described as the “quality without a name.” Alexander could be construed as an architectural philosopher.
More relevant today is the influence these books have had on modern software development. One of the notions Alexander had was that he could express an architectural ideal in terms of a somewhat structured form he called a pattern. A pattern is simply a recommended approach to a solution, given a certain context. For example, one of Alexander’s pattern is known as “six foot balcony.” The pattern expresses the conflict: no one uses balconies or porches that are less than six feet in depth. Alexander then provides the resolution: make the balcony more than six feet, and recess it into the building if you have to. Pretty simple stuff.
Kent Beck and Ward Cunningham in the late 1980s expressed a series of Smalltalk GUI idioms in a similar pattern fashion. The 1995 book Design Patterns formalized this concept further. It contained 23 software design patterns that the four authors (Gamma, Helm, Vlissides, and Johnson, aka the Gang of Four) had recognized from commonly occurring software design solutions. Now the software community had common names for these solutions as well as a de facto standard pattern form.
Since then, patterns have been all the rage. Publishers have released gobs of books on patterns. Conferences and web sites are devoted to patterns. It’s rare to go on an interview anymore and not be asked about patterns.
The best thing patterns do is provide everyone with a common means to communicate problems and solutions. The fact that interviewing almost universally includes pattern discussions is a testament to the success of the patterns movement.
Like all movements, the patterns movement went a bit overboard. Novice developers demonstrated that it’s easy to learn one hammer-like pattern and then wedge it into every possible space in software. Worse, people seemed to get the idea that by having patterns in your system, you automatically had a good design. Sure, most patterns espouse good design, but stuffing a few patterns into code doesn’t impart good design to the rest of the system. You have to understand what good design is all about to end up with it.
Ultimately, it is a good thing to learn about software design patterns. Agile development teaches you to let the pattern emerge, not force it where it might not fit. While there is still a bit of art to software development, it is more a craft. Patterns provide a craft-oriented, structured tool that can provide a growing foundation for the art.
Odder, some software developers began to worship Christopher Alexander. Patterns became gospel, and Alexander become God-like. Discussions about Alexander include glowing terms, and I suspect some software developers read his material more than they read software books.
Recently, I talked with an architect for the first time since I’d heard of Alexander. I mentioned the name. “Never heard of him!” I was dismayed. I surmised one of two things: either Alexander has more sway in the software industry than the architecture industry, or architects today are like any other profession where most of the people in it know nothing beyond their cubicle. I posed this thought on an XP coaches list. The respondents, some of who included well-known names in the software design industry, had all had similar experiences. Either the architect had never heard of Alexander, or scoffed at the mention of the name.
Digging a little, I affirmed that Alexander has indeed fallen out of favor (which he may have never had) in the architectural world. His ideas appeared either threatening or ridiculous to other architects. Threatening, because one of the things Alexander suggested was that people, not architects, are capable of designing their own structures. This idea carries into the software industry with XP, which suggests that programmers are capable of architecting and designing systems on their own. XP believes that a separate non-programming software architect is not necessary. Naturally this threatens non-programming software architects.
In any case, I find it quite amusing that many software developers worship a guy who is scorned by many of his peers. But I still believe that software patterns have added a lot to the knowledge base of software development. You owe it to yourself and your career to understand what software design patterns are all about, if you don’t already. Just don’t turn it into a religion.
I recently turned 40. I don’t feel a day over 20, at least from my mentality. Sure, I’m a cranky curmudgeon, but I think I’ve always been that way. In fact, I think I’m far more mellow now.
Some people are 40 the day they turn 20. And they stay that way. So certain of their viewpoints and knowledge, anything else someone suggests to them is a quickly-dismissed challenge.
If there’s one thing that’s most frustrating about the software development industry, it’s that there are so many people that just “know everything.” The mentality needed to build software often suits a sharp, independent, but stubborn mind. Once something works for them, no matter how well it works, developers often have a tough time accepting the fact that something else could work equally as well or better.
Building a successful software team is about finding the right mix of people, and the people with the right attitude. If the team members learn to question themselves as often as they question each other, you’ll probably be fine. If you have “questioning strata,” success will be difficult–it’s hard to get the self-assured down from that upper rock.
When hiring, get rid of your three-and-four-letter acronym laundry lists. Instead, you’re looking for an equal balance of smarts and humility. As far as the “smarts” side of things, check out Joel on Software’s “The Guerilla Guide to Interviewing” for some interesting ideas on how to interview candidates.
As far as the humility measure? It’s tough to ferret it out in an interview, for the goal of an interviewee is to promote self-confidence and success. I like to first ask questions about the things that people enjoy doing, and what gets them riled up. Try pushing a few buttons–it’s not too hard to get the superego to emerge. But the best way to find out is to sit down and try solving a few coding or design problems together. See how enthusiastic your candidate is about explaining things to you. The more important thing than them knowing everything is for them to be able to patiently explain the things they do know.
“You can’t teach an old dog new tricks” is an absolutely true phrase–just remember that old dogs often come in new stripes.
When creating an executable jar (one that can be kicked off with -jar), make sure that the Main-Class entry ends with a line separator. If you accidentally type a space after the class name, it won’t work; you’ll get a NoClassDefFoundError when trying to execute against the jar.
Shades of makefile spaces instead of tabs problems. Developers that build space-specific code should be shot. If you want to make your code whitespace-specific, you should have to write it in the Whitespace language.
With the goal of delivering quality software, I can help you with:
Want to hear more? Call 719-287-GEEK or use the Contact Me form to the left.