Feeds

Hafta Man and the threat to agile design

Pragmatism, not grand plans

Intelligent flash storage arrays

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.

Providing a secure and efficient Helpdesk

More from The Register

next story
UNIX greybeards threaten Debian fork over systemd plan
'Veteran Unix Admins' fear desktop emphasis is betraying open source
Netscape Navigator - the browser that started it all - turns 20
It was 20 years ago today, Marc Andreeesen taught the band to play
Redmond top man Satya Nadella: 'Microsoft LOVES Linux'
Open-source 'love' fairly runneth over at cloud event
Chrome 38's new HTML tag support makes fatties FIT and SKINNIER
First browser to protect networks' bandwith using official spec
Admins! Never mind POODLE, there're NEW OpenSSL bugs to splat
Four new patches for open-source crypto libraries
prev story

Whitepapers

Forging a new future with identity relationship management
Learn about ForgeRock's next generation IRM platform and how it is designed to empower CEOS's and enterprises to engage with consumers.
Why and how to choose the right cloud vendor
The benefits of cloud-based storage in your processes. Eliminate onsite, disk-based backup and archiving in favor of cloud-based data protection.
Three 1TB solid state scorchers up for grabs
Big SSDs can be expensive but think big and think free because you could be the lucky winner of one of three 1TB Samsung SSD 840 EVO drives that we’re giving away worth over £300 apiece.
Reg Reader Research: SaaS based Email and Office Productivity Tools
Read this Reg reader report which provides advice and guidance for SMBs towards the use of SaaS based email and Office productivity tools.
Security for virtualized datacentres
Legacy security solutions are inefficient due to the architectural differences between physical and virtual environments.