- Consulting / Coaching
- Jeff’s Blog
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.
Requirements, requirements. There are few things worse to me as a developer than having to guess what I’m supposed to build. I’m currently in a shop where we get high level requirements from an end customer, but the details are left to us.
–“Should this have a default, Bill?”
–“I dunno, what do you think, Jeff?”
–“I dunno, what do you wanna do, Marty?”
Ugh. It’s a huge comfort to have someone take the time to find out what we should really be building.
Welcome to my blog. While I’m going to concentrate more on the mini-articles located in the Articles section [[self-hosted entries since moved to the blog!]], I’ll use this as a source of very brief reflections on things as they occur to me. In fact, I’ll probably forget that I even have this blog thing for a while…
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.