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.

High performance access to file storage

More from The Register

next story
Android engineer: We DIDN'T copy Apple OR follow Samsung's orders
Veep testifies for Samsung during Apple patent trial
This time it's 'Personal': new Office 365 sub covers just two devices
Redmond also brings Office into Google's back yard
Batten down the hatches, Ubuntu 14.04 LTS due in TWO DAYS
Admins dab straining server brows in advance of Trusty Tahr's long-term support landing
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
Windows XP still has 27 per cent market share on its deathbed
Windows 7 making some gains on XP Death Day
Internet-of-stuff startup dumps NoSQL for ... SQL?
NoSQL taste great at first but lacks proper nutrients, says startup cloud whiz
Windows 8.1, which you probably haven't upgraded to yet, ALREADY OBSOLETE
Pre-Update versions of new Windows version will no longer support patches
Microsoft TIER SMEAR changes app prices whether devs ask or not
Some go up, some go down, Redmond goes silent
Red Hat to ship RHEL 7 release candidate with a taste of container tech
Grab 'near-final' version of next Enterprise Linux next week
prev story

Whitepapers

Securing web applications made simple and scalable
In this whitepaper learn how automated security testing can provide a simple and scalable way to protect your web applications.
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.
HP ArcSight ESM solution helps Finansbank
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.
Mobile application security study
Download this report to see the alarming realities regarding the sheer number of applications vulnerable to attack, as well as the most common and easily addressable vulnerability errors.