This article is more than 1 year old
Hafta Man and the threat to agile design
Pragmatism, not grand plans
This bloke once walked into a meeting I was attending and introduced a new word to my vocabulary: "Hafta", as in: "We hafta do it this way because..."
I've been trying to shake it off ever since.
Hafta is really a design mindset - albeit an especially poor one. Broadly speaking there are three attitudes to design:
1. We hafta do it this way because...
2. Wouldn't it be great, if it could work this way...
3. My grand design is just getting started!
These represent three successive plateaus, with number two really being the sweet spot.
The hafta mindset usually leads to compromises and decaying designs. It's a defeatist attitude disguised as pragmatism. This mindset is easy to spot in the wild. Explanations such as: "Yeah well we have to do it like this, because the Trade Blotter team's client API demands X,Y and Z..." are usually accompanied by an apologetic shrug of the shoulders and a wan smile.
If your team just keeps falling back on haftas and rationalizations, you'll inevitably end up with an architecture that's built on compromises and is difficult to extend or modify, stuck with ancient APIs, hampered by duplicate data across several databases, and handicapped by disparate systems reinventing each others' wheels using incompatible data formats or protocols. That sort of thing.
Onto the next plateau. The "wouldn't it be great, if" attitude is the agile mindset, and is the ideal to strive for. But you'll hear people rubbish this approach because they confuse "ideal" with "idealistic". That is, they'll tell you that spending more time getting it right is just making the project take longer. But not spending that time will result in all the problems I just described.
With this mindset, teams refuse to compromise. They'll thrash out the details until they have an optimal solution, even if it means rapping on the partition of the Trade Blotter team and demanding a rethink of their crappy client API.
With this approach, the overall system evolves into a thing of great quality, devoid of the warts and boils that afflict the hafta teams. New functions are easy to add on because different parts of the project work well together. Duplicate functionality, meanwhile, is stomped out before it can take old.
If your team adopts this mindset, you'll often hear them mentioning maintainability and figuring out how the system can be improved with each new feature. They'll also be geared towards providing value to the business rather than just checking out the latest enterprise design pattern.
That brings me to the final plateau - the "grand design" that soars several hundred meters higher than the others. Anyone who's suffered through too many Discovery Channel pieces about explorers wandering up Everest, becoming disoriented and getting in trouble will be familiar with the facts that at such giddy heights there exists virtually no oxygen. Peoples' thinking turns cloudy and judgment impaired. Yet teams so often seem to push their design way up to this great height of vision.
The "grand design" mindset is the antipattern. It's basically number two on our list taken too far, and is a lurking danger of the refactoring state of mind. Picture a pluggable framework that only ever has one plug. The framework is there "in case we need it later", but is really just more complexity to maintain. It's incredibly easy for well-meaning developers to fall into this trap.
I'll delve deeper into the grand design mindset next time.
It's surprising how often a team falls into the first mindset, because they think they're being pragmatic and how often a team dismisses the second because they mistakenly think it's ivory tower. It's also surprising how often a team falls into the trap of striving for the grand design, because they think they're saving their project.
Learning to spot these attitudes and acting on them, though, can turn out to be a real project saver.®
Matt Stephens co-authored Use Case Driven Object Modeling with UML: Theory and Practice, which illustrates how to create the ideal - rather than idealistic - software design with Enterprise Architect, Spring Framework and JUnit.