As bad as anything else

2012 06 29

Generic Piece Of Technology

This is a topic that has been annoying me for a while, in fact, since I started working professionally with code. It doesn't apply to anywhere specific (read: not my current work place), but just to general observations made.

Ever heard of Given Generic Piece Of Technology (GGPOT)? Possibly. Best chance is you've heard of it in principle, thought it might have looked good, but used it in some corporate environment where it became buzzword paradise. SOAP, heavy XML, CORBA, REST, web services, strict specifications, and if you're particularly lucky, you had the pleasure to work with WSDLs.

What appeared to be the original principles behind GGPOT (loose coupling, abstraction, reusability, autonomy, encapsulation, etc.) quickly turned into architecture astrology, acronym hell. And it's not as if GGPOT was the first thing to promise things such as reusability. Every method or technique flaunting these advantages that gets widely adopted appears to inevitably turn to shit.

Somewhere, in some big corporate architecture building, someone sees these things and decides "I know, I'll use it for everything". In the regular world, I figure this would be equivalent to saying "Hey this perfume smells good. Let's bathe in it, cook with it, drink it, and use it as mouthwash!" Of course it's gonna be bad.

But GGPOT is supposed to be good. We have money invested in this. We have to look for something else. Maybe our Current Methodology is off marks? Maybe what we need is some Given Generic Piece Of Methodolgy (GGPOM)?

When methodologies of this kind go bad, we give them up and move on to something else. It's easy to do; pick a new one that flaunts the same principles of better budget respect, good team cohesion, and code quality. We can then declare ourselves lean, agile, and flexible rebels, and let it slowly bubble up to unmanageable sizes again, because we want the image and feel of change, not the discomfort that goes with it. We don't want to upset management nor employment structure, and not changing the team would be a plus. And then we start the cycle over again.

True, true. It would probably be more efficient to measure different things, try to understand the problem at hand at the risk of taking a bit longer, and making sure we pick something appropriate. Maybe it'd be useful to accept mistakes as part of a standard process. The products we grow are never done, but boy do we wish the spending could stop! Continuous refinement costs money. Maybe it's better to keep drowning ourselves in GGPOTs and pretending to implement all these GGPOMs, hoping at some point we hit the optimal one, rather than going for a decent solution.