A web application is no longer a bunch of CGI scripts. Web applications can be as rich and complex as traditional software, and as software becomes more sophisticated it is increasingly critical that it is well structured and sensibly managed.
Let’s find out how not to do exactly that using antipatterns!
Since this article is all about being contrary, let’s look at what an antipattern ISN’T.
Definition: In computer software a design pattern is a reusable approach to solving a commonly-occurring software design problem. A design pattern is a template for solving a problem that can be used in many different situations. – about.com.
Antipatterns are the antithesis of a pattern – they are definable ways of making things horrible and terrible. Antipatterns are to software what being stuck in a lift with Jar Jar Binks is to personal space – invasive, unpleasant and downright frustrating. And, like everyone’s least favourite cyber puppet, software suffering from antipatterns can benefit from a good beating with the clue by four.
Design patterns are generally quite well defined, but antipatterns can afford to be pretty loose. Let’s take a look at a few of the abominations in the Bestiary of Badditude!
The golden hammer antipattern is the belief that one magical technology product or approach is sufficient for all needs. Perhaps because “we’ve always done it this way” or “it worked on Project X”. Belief in a golden hammer can result in such bad craziness as having presentation html be served from within stored procedures <shudder>.
Besides, gold is a silly thing to build a hammer out of. It’d be too soft.
So George, an anthropomorphic personification of a software framework walks into a software house (stop me if you’ve heard this one before. You may wish to stop me anyway).
Software house: “Who are you? We don’t take kindly to strangers around these parts.”
George: “I’m a framework! I take care of a lot of the heavy lifting for you and save you lots of time!”
Software house: “We don’t have no truck with that kind of shenanigans here. We put in hours of good, honest graft and write our web pages in Assembly! Be off with you!”
George: “But, just try me out! I’m sure you’ll like me!”
Software house: “We’re much too busy, after all, it takes 10 hours to build each web page this way! Now get out!”
Also known as NIH syndrome, this is a wonderful way to squander resources and reinvent the wheel.
Working on the web, we are particularly vulnerable to Continuous obsolescence – new frameworks, languages and techniques come out every day. It can be illustrated like this:
“OK! We’ve ported our C++ app to CGI on the web!”
“Great! But there’s this new thing, ASP, that is new and shiny, let’s use that!”
(later) “OK, we’ve just finished the port from CGI to ASP!”
“Umm, OK guys, but ASP.Net has just been released, can we port to that? Also, can we have Flash animations?”
(later still) “OK, now the UI looks dated, let’s switch to jQuery animations…”
Performance is important, particularly on the web (see our blog post on progress bars for some info on how slow performance can annoy users) so we must optimise our code. Precisely the wrong thing to do is to assume you know what will make a given system slow without testing it. Optimising too soon in the development process can result in a clumsy architecture. Sometimes we do have to mar our beautiful designs for the sake of speed, but just blindly assuming that ugly hacks will improve the product is foolish: we must also factor in developer time, code comprehensibility, and many other factors, and if your code reads like a phonebook that’s been through a paper shredder, you’re in trouble. Most of the time, a good architecture stands you in good stead because it will scale cleanly.
That said, it is always prudent to profile your code, to find where it is actually slow, rather than the assuming it’s slow where you think it is. For example, YSlow is a great tool to help us to measure front end response times on the web, and XDebug with a cache grind program can help you to find where your PHP is bottlenecked (other languages and tools are available).
I’ve made a little rhyme to help you remember:
Be like Eric Morecambe,
Not like Ernie Wise,
Profile your sourcecode,
Before you optimise
Sadly, the big ball of mud antipattern describes most software products: a casually or haphazardly constructed system. There is no kind of structure, just a Hungry Hungry Hippos style free for all. These kinds of systems are the most vulnerable into devolving into our next antipattern, the post-apocalyptic wasteland of many a software project:
Some web projects take the concept of a “digital frontier” a bit literally, practically issuing cowboy hats and six shooters to their developers! These projects have no version control, and developers jump onto boxes, hack in changes and log off. This can result in a tangled mess of code (a spaghetti code western, perhaps), often incorporating other antipatterns such as copy and paste programming. Such a project will soon reach critical mass, particularly as there is no definitive codebase.
Fire fighting can be exhilarating in the short term, but it eventually becomes dispiriting, and there’s nothing for it for the cowboy to do but to saddle up and ride off into the sunset, ready to screw up another project.
As a brief and hopefully fun crash course, this hasn’t been an exhaustive treatment of antipatterns by any means; there are many more (Ward Cunningham’s wiki has a list). Even software houses that are “doing it right” may exhibit antipatterns in test driven development. On the web, we’re just as vulnerable to falling into bad habits as with traditional software development. Let’s be careful out there, people.