Mediocre programmer (anti)patterns

I found this astonishing blog by Steve Smith here. I’ve just reported the mediocre patterns followed in many companies all over the world described in the post plus 3 I was thinking yesterday.

Give yourself this try. Read them all in a row, and if you mind complete the poll at the end, to see how much they reflect you/the SDLC followed in your workplace.

Fast Beats Right (FBR)

– It’s more important to get something done that probably works, or that works right now even if it will be hard to change later, than to spend time ensuring that it is correct or is well designed.  This is classic “cowboy coder” or “duck tape programmer” thinking, and sometimes management may be OK with dictating that for a given feature or prototype, speed is more important than anything else….

Feaping Creaturitis Driven (FCD)

– A project built using FCD never, ever has a cycle that completes appropriately. Just when you can see the horizon, someone on the team adds yet another nozzle or value that they are desperately in love with.

Assumption Driven Programming (ADP)

– Rather than wasting time thinking about edge cases, assume that the user will only use your software the way you mean for them to, and that nothing bad will happen.  This is the quickest way to knock out a feature and be able to demo it to the customer anyway (as long as you are in charge of the demo script), and besides, it should be obvious to anyone how they’re supposed to use the application, so it’s the user’s fault if they do something unexpected.

Some typical “Assumptionist” questions:

“What do you mean, you can’t change the configuration on a shared host?”

“Why would the user type garbage in the address bar?”

“Who would try to put a script file through this image upload form?”

“Why would someone type SQL into a textbox clearly labeled ‘username’?”

ADP often leads to uncaught “sad path” bugs and security holes.

Telemarketer Principle (TP)

– Programming is about control, and the best way to ensure that your software does exactly what you want is for you to manage exactly when and how it behaves at all times.  The Telemarketer Principle is summed up as “Make lots of calls to anything you might need in the system for your program.”  If you cede control to other modules or let the system or a framework do things on your behalf, can you really be sure they’ll do it right?  And just in case, don’t forget that for anything really important you can always Reinvent The Wheel (RTW) and call your own routine all over the place instead.

Static Cling Pattern (SCP)

– Static (global) methods and objects are often an expedient way to add some functionality to an application without spending any time worrying about where the “right” place for it to live might be.  Using static methods for truly stateless operations that work only on the parameters passed in and do not have any other dependencies is fine, but problems arise when static methods instantiate objects or call other methods outside the scope of the passed in parameters.  Once this has gone on for a while, it can be very difficult to introduce seams into the application to decouple its components from one another – it has begun to suffer from “static cling”.

Vestigial Structures Pattern (VSP)

– When features are removed that span multiple tiers, the bits that are no longer used are left behind “just in case.”  …  a vestigial structure may retain lesser functions or develop minor new ones.

Flags Over Objects (FOO)

– Instead of using objects, polymorphism, or delegation, it’s much faster to just add a flag to a class and expose it.  Then anywhere in the system that cares about that condition can simply add an if(foo.IsBar()) { … } clause to deal with this condition.  Who needs inheritance?

The God Class (TGC)

– Everybody knows that object-oriented programming is great because it lets us leverage and reuse classes to do all the work in our programs.  And of course, nobody wants to have to look for the right class to do something, and the more classes you have, the less powerful each one is.  It’s much better to just write (in Lord of the Rings voice here) one class to rule them all, a master class, capable of doing anything and everything your application might require.  And who cares if it’s 5,000 lines of code?

Data Driven Architecture (DDA)

– Professional developers know that building applications in layers or tiers is a best practice.  The traditional approach is to have at least 3 such layers: UI, Business, and Data.  When organized following the DDA pattern, the Business Layer will reference the Data Layer, and the UI Layer will reference the Business Layer.  This is obvious, since clearly the Business Layer needs to be able to fetch and persist data, so it has to reference the Data Layer, and the UI layer needs to provide an interface to the Business Layer, and so must reference it.  The benefit of this layered approach is that the Data Layer could, theoretically, be completely rewritten without any changes being made to the UI layer.  Only the layer one step up would need to change (and it must change, since any interfaces used can’t belong to the Business Layer using this approach, because then the Data Layer would need to reference the Business Layer in order to implement such interfaces, creating a circular reference.

Found On Internet (FOI)

– When faced with a problem, the quickest fix is often to search the Internet.  This is a valuable and effective way to research solutions.  The mediocre programmer’s approach to this, however, is to locate the first blog post or forum response that looks like it might be a fit to the problem at hand, and then to cut and paste the code, hack at it until it compiles, and run the application to see if it seems to work.  If it does, move on to the next fire.  If not, continue hacking until it does or go to the next item in the search results.

Copy-Paste-Compile (CPC)

– Sometimes an application exhibits a bug or requires new functionality that has already been corrected elsewhere.  All that needs done is to locate the correct section of code, copy it, and paste it into the section of code that requires this behaviour.  Make sure it still compiles and check it in.  Another task complete!

Reinventing The Wheel (RTW)

– Part of an application requires a little algorithm or utility that no doubt someone else has encountered before, but rather than using an existing framework class or well-known industry solution, the developer takes this as an opportunity to write the best XXX utility ever.  …

Copy Folder Versioning(CFV)

– Sometimes, changes to an application are big enough that they seem scary (even to a cowboy coder), so they decide to make a backup.  Of course, there’s no source control software in use, so naturally the way to go is to make a copy of the folder containing the project (and, if you’re being extra professional, rename it from “Copy (2) of FooProject” to something more useful).

Golden Hammer (GH)

– The Golden Hammer refers to a particular language, framework, library, or tool with which you are familiar, and with which you’re certain you can solve any problem.  When wielding the Golden Hammer, every obstacle looks like a nail, and any suggestions by teammates that other tools might be better-suited to the task at hand go unheard. (aka Silver Bullet, Magic Bullet)

Shiny Toy (ST)

– The Shiny Toy is latest, coolest tool or technology available.  Its potential is boundless.  It can solve world hunger and bring about lasting peace in the Middle East.  But it’s still beta so of course you need to spend some time learning it, since there’s no documentation for it yet and nobody you’ve heard of has released a live application running with it.  You’re sure it will do everything the application needs, though, without too much extra effort…

I would like to add other 3 I found recently…

Oracle Knowledge WORKMATE (OKW)

— The Oracle Knowledge Workmate is when your workmate keeps secret the knowledge of the system on which he is working to avoid other people to be independent to add new functionality on top. This make him feel good as he thinks –(un)disposable, but at the end is … very bad specially when he’ll leave the company and or project.

Talkative requirement (TR)

— Why to keep an official requirement on a doc when you can just use a monkey developed to change everything when you realize your requirement were very week and you didn’t ask for the important part of the project to the customer… just fire  bugs and change everything.

Never coming changes (NCC)

— Ok you talked with your boss/prj manager and you go through a list of what doesn’t work, They say yes will do that, we agree (and they really agreed). After 6 months nothing is changed, because they are used to be static…



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s