Feeds

Hafta Man and the threat to agile design

Pragmatism, not grand plans

High performance access to file storage

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.

Combat fraud and increase customer satisfaction

More from The Register

next story
This time it's 'Personal': new Office 365 sub covers just two devices
Redmond also brings Office into Google's back yard
Inside the Hekaton: SQL Server 2014's database engine deconstructed
Nadella's database sqares the circle of cheap memory vs speed
Oh no, Joe: WinPhone users already griping over 8.1 mega-update
Hang on. Which bit of Developer Preview don't you understand?
Microsoft lobs pre-release Windows Phone 8.1 at devs who dare
App makers can load it before anyone else, but if they do they're stuck with it
Half of Twitter's 'active users' are SILENT STALKERS
Nearly 50% have NEVER tweeted a word
Internet-of-stuff startup dumps NoSQL for ... SQL?
NoSQL taste great at first but lacks proper nutrients, says startup cloud whiz
IRS boss on XP migration: 'Classic fix the airplane while you're flying it attempt'
Plus: Condoleezza Rice at Dropbox 'maybe she can find ... weapons of mass destruction'
Ditch the sync, paddle in the Streem: Upstart offers syncless sharing
Upload, delete and carry on sharing afterwards?
New Facebook phone app allows you to stalk your mates
Nearby Friends feature goes live in a few weeks
prev story

Whitepapers

Top three mobile application threats
Learn about three of the top mobile application security threats facing businesses today and recommendations on how to mitigate the risk.
Combat fraud and increase customer satisfaction
Based on their experience using HP ArcSight Enterprise Security Manager for IT security operations, Finansbank moved to HP ArcSight ESM for fraud management.
The benefits of software based PBX
Why you should break free from your proprietary PBX and how to leverage your existing server hardware.
Five 3D headsets to be won!
We were so impressed by the Durovis Dive headset we’ve asked the company to give some away to Reg readers.
SANS - Survey on application security programs
In this whitepaper learn about the state of application security programs and practices of 488 surveyed respondents, and discover how mature and effective these programs are.