Feeds

Frameworks and the danger of a grand design

Hard-lesson learned

Combat fraud and increase customer satisfaction

It's probably safe to say that we've all succumbed to the "grand-design mindset" at one stage or another. It's a critical stage in a developer's growth: the dawning awareness that design matters, an earnest desire to write good code but without the bitter lessons that the reality of an over-designed project will soon fling at you.

The developer at this stage hasn't yet learned the hard way, that you can get too much of a good thing. This isn't really something that can be taught, at least not in such a way that it really drums the lesson home. You have to experience the pain of creating an over-designed "framework for the sake of it", believing in all good faith that your grand design will help, not hinder, maintainability.

The grand design mindset isn't just the application of an anti-pattern, or even just the inappropriate use of a normally well-behaved design pattern. The mindset is the overuse of patterns, carefully cementing nano-thin layers of indirection atop each other like a process in a chip fabrication plant that can't be shut down. It's the naïve belief that if X is good then 100X must be better every time.

Luckily this mindset is easy to spot. Your team members will be busy creating a beautiful but over-designed system with enums, annotations, closures and all the latest language features, loosely coupled classes and several hundred pluggable frameworks when a well-placed isThisTheRightValue() method would probably have sufficed.

Picture a pluggable framework that only ever has one plug. You'll see a comment in the code like:

    // Later this could be applied to other parts of the system. 

If there's neither time nor a compelling reason to apply the pluggable framework to other parts of the system in this iteration, then it's likely the programmer going off on a design pattern hike - exploring their talents - and the framework should be struck out of the code. It's just more complexity to maintain.

Of course, some programmers will never learn: they like writing code too much. Lots of it, as if they're paid in lines of code, or reviewed that way. Or maybe it's a macho thing. Pursuing your own grand design will do that for you, but it's better to solve problems with little code. Less is more.

Modern refactoring tools make it way too easy to fall into the "grand design" trap, with developers encouraged to develop the design as they're coding it. The refactoring tools are fast and sweeping. Radical design changes are just a keyboard combo away.

It's nice to think of refactoring as "redesigning at the speed of thought". But it isn't, it's refactoring faster than the programmer can think about the design and reflect on its implications for the rest of the system. The programmer is too immersed deep-down in the code to really appreciate the design from a higher level. So grand designs emerge before the programmer realizes it.

To develop their own design skills beyond the stage of the grand design, programmers must recognize that any time they're creating reusable code, they're writing a framework. It could be a modest one-class framework, or a system-wide thing of great complexity (like a data access object layer or presentation layer, for example). The developer must then also twig some important things about frameworks:

1. A bad framework is far worse than no framework at all

2. Good frameworks are hard to get right

3. You probably don't want to be writing your own framework anyway (or even seeking out a third-party one, for that matter)

Sometimes, specific, non-reusable code just hits the spot, because it gets the job done with a minimum of complexity. But sometimes, you do want code to be re-usable because you can see exactly where it'll be re-used. Having an overall design and an understanding of the broad set of requirements helps to identify whether re-usable code is needed.

But without stumbling upon this hard-earned lesson - without that Eureka! moment - the well-meaning developer will be stuck with a grand-design mindset forever.®

Matt Stephens is co-author of Use Case Driven Object Modeling with UML: Theory and Practice, which illustrates how to drive functional tests and unit tests from use cases, using the Spring Framework, JUnit and Enterprise Architect.

High performance access to file storage

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
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
Oh no, Joe: WinPhone users already griping over 8.1 mega-update
Hang on. Which bit of Developer Preview don't you understand?
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
Ditch the sync, paddle in the Streem: Upstart offers syncless sharing
Upload, delete and carry on sharing afterwards?
Microsoft TIER SMEAR changes app prices whether devs ask or not
Some go up, some go down, Redmond goes silent
prev story

Whitepapers

Designing a defence for mobile apps
In this whitepaper learn the various considerations for defending mobile applications; from the mobile application architecture itself to the myriad testing technologies needed to properly assess mobile applications risk.
3 Big data security analytics techniques
Applying these Big Data security analytics techniques can help you make your business safer by detecting attacks early, before significant damage is done.
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.
The benefits of software based PBX
Why you should break free from your proprietary PBX and how to leverage your existing server hardware.
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.