Mistakes in Platform Selection

Emotion is a Poor Substitute for Facts

In the old days of MS-DOS, as you might recall, every computer included a quaint little programming environment called GW-BASIC. What you may not recall is that you could write object oriented programs using GW-BASIC. Don’t believe me? It’s true! All you need to do is develop a framework that maps object-oriented principles onto the limited procedural mechanisms provided by GW-BASIC.

Of course, you would need to come up with a way to simulate method calls, most likely using pre-defined variables that you could pretend were parameters when you GOSUB’ed. And then you’d need arrays to store member variables, and some way to manage those arrays…

Now, you’re probably thinking, “But that’s not really OO programming. You’re just shoehorning an OO-like mechanism onto a system that was never designed for it…” which would (hopefully) then be followed by, “Oh hey now, I see where you’re going with this…”

Now I’ve never heard of anyone ever trying to do such a thing, but if you were a person who really loved GW-BASIC, I’m willing to bet that the idea of trying to accomplish such a thing would have crossed your mind at some point. And people have done such things using more advanced languages such as C.

But this contrived example demonstrates a trap that developers fall into more often than they would like to admit: they choose a tool because of a personal affection for it or because they perceived it to be the Cool New Thing fortified with Silver Bullets™, rather than because of merit and appropriateness.

Development proceeds, in one of three possible directions.

If you’re lucky, the poor decision will be realized early on in the development cycle, and things can be re-evaluated with minimal loss.

If you’re lucky enough to have remarkable programmers working on your project, they may be able to complete the project despite the handicap, but future maintenance will be still very much in doubt.

But the most likely scenario that the project will keep going and the best you can hope for is that the project will be finished before your bank account is. The final result will be a monstrosity that is over budget, well past its deadline, and so nightmarishly constructed that you pity the poor souls down the road that are tasked with maintaining the thing.

There are websites dedicated to such software, such as http://thedailywtf.com, which has a veritable buffet of such monstrosities. Well-publicized failures include the London Stock Exchange abandoning a hugely expensive trading platform that was written using .NET because the end result was unacceptably slow. Twitter’s use of Ruby on Rails was considered revolutionary, until Twitter became popular and started keeling over because RoR was incapable of scaling to meet demand1.

I have personally seen a company where the higher-ups were so emotionally invested in a contact/sales management system a friend of theirs had sold them on, that they refused to change despite warnings of how bad it was. The end result was a system that brought the business to a grinding halt countless times, and provided none of the insight that the stakeholders wanted.

So how do you avoid this trap?

You need to look at your objectives and consider the tools at your disposal with a critical eye, not an emotional one. Different languages (and different frameworks based on those languages) have different strengths and weaknesses. Your focus, and the compromises you make, should be based on what the project actually needs, rather than what you personally want. If you think to yourself, “This is an important project. I want to write it in a real programming language like Java, not one of those hokey scripting languages like Python” then you’re already going down the wrong track before you’ve even started.

There is a related (but more difficult to foresee) issue when you are trying to choose a platform for your project. You do your due diligence, comparing the features that each option provides, and finally make what you think is a good choice. It’s not until you’ve begun development in earnest that you realize that the system doesn’t do exactly what you thought it did. Worse, it could be a disturbing amalgamation of pieces held together by duct-tape and bubble gum. It may even be necessary to rewrite large swaths of what should have been built-in functionality because what you got was never actually fit for purpose. Besides increasing the frustration level of all concerned, you risk hasty decision making and rushed, sloppy code as you try to make up for time lost.

If you are looking at the capabilities of various tools in isolation, this pit is extremely easy to fall into. It’s also not trivial to avoid, as the only solution is experience. If you’ve never worked with the tool in question, then it behooves you to consult with someone who has. If that isn’t possible, then you should try kicking the tires by first implementing a small scale test project using said tool. It’s far better to lose a few days trying out your tool, than to lose a few weeks or months because you realized too late that your chosen tool wasn’t the godsend you thought it was.

Just to add another wrinkle to the formula, if one of the tools you look at doesn’t include the features you need out of the box, it may have the ability to extend the core functionality in some way via plugins or other forms of customization. While not as conceptually clean as an all-in-one solution, the results can be surprising. Again, experience is the key.

A good example of this is the open source content management system Drupal. When I first saw Drupal, I thought it was conceptually sloppy and fraught with peril. Design-wise, it is very analogous to the “Writing OO in GW-BASIC” example I gave earlier on. However, the developers successfully negotiated the tightrope to create a surprisingly robust system, with a massively large community to prove it. But like the lottery, for every winner there sure are a lot of losers. While I won’t name names to protect the guilty (and us from lawsuits), I will say that I never would have imagined software being capable of inducing PTSD.

Software Always Lasts Far Longer Than You Expect

Remember the Y2k bug? A dozen years ago, the world’s biggest freak-out occurred because innumerable systems were at risk of rolling over from 99 to 00. Huge quantities of software had been written to only handle the last 2 digits of the year. The early developers of the 70s and 80s could be forgiven for this mistake, because computing resources back then were limited and every byte counted, and everyone expected the software to be rewritten by then anyway. Shockingly, there were people still doing this in the 90s as well.

When the year 2000 loomed, all sorts of doomsday predictions were made. While some claims like planes falling out of the sky were preposterous, other possibilities were far more plausible and likely, such as mortgages being improperly foreclosed or seniors unable to get their pension checks. But in the end, nothing happened. Those unaware of the details ironically said that the whole thing was overblown, and that “crisis” was a waste of effort and money. But the fact is that it was that massive effort, the billions of dollars spent2, the hundreds of thousands of hours of labour pouring over every major piece of software written in the last 3 decades that prevented a catastrophe. The reason nothing happened was because a lot of people did their jobs, and did them well. And that is how it should be.

There was a great deal to be learned from that episode. The biggest lesson is that any software you put in place is likely going to stay there for a very long time. It has been said that there is nothing more permanent than a temporary solution. You must assume that the software will run far longer than you would have expected or intended. Thus when selecting your tools for your project, consider the longevity of said project. As your business needs evolve, will the software you made 5 years ago still be up to the task? Was it written using industry best practices, such that a new person would be able to sit down and make revisions without spending two weeks wondering what was even on the screen? If you had another company develop the software for you, did they give you the source code and necessary documentation so that if the original developer disappeared, you could still continue to make changes?

I have the pleasure of working at Jonah Group, a company full of experienced technologists who understand the tradeoffs discussed in this article. We can help you navigate the terrain, if need be. Just contact us at jonah-info@jonahgroup.com.

1. http://www.readwriteweb.com/cloud/2011/04/twitter-drops-ruby-for-java.php
2. http://en.wikipedia.org/wiki/Year_2000_problem

Add a comment

Comment feed
The better to greet you with
No one will ever see this
Your pride and joy
The reason this comment form exists

The crew behind ASOT

We're a team of interactive, software, and business intelligence experts skilled in the design, construction, and management of online enterprise systems.

Visit The Jonah Group site

Get in touch with us