October 24, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

Today’s Platform Decisions

  • December 3, 2013
  • By Rob Bogue
  • Send Email »
  • More Articles »

Development today is different than it was even 10 years ago.  There’s the obvious shift towards JavaScript – for which there has been much wailing and gnashing of teeth.  However, those changes are just the first layer of the onion.  Behind that are the questions of which platform or library you should use to build a solution.  Do you build the solution yourself with a good probability of knowing when you’ll be done or do you look for a shortcut to possibly get a better solution done quicker.  That’s the build vs. buy decision of today.  It’s not about whether we’re buying off the shelf software or whether we’re developing it – but rather how much of it we’re developing.

What Platform Are You Standing On?

When you use the word platform in a development context the quick assumption is that we’re talking about operating systems.  In other words, the assumption is the question of whether the platform is Windows, Linux, Mac OS, iOS, Android, Windows Phone.  However, there’s more to it than that.  If you’re building a solution today there’s more than just base level operating system platform services that you may want.

A platform may come in the form of a prepackaged software solution that is designed to be extended – like Microsoft SharePoint – or it can come in the form of one of the libraries that have been developed to be plugged in and used by developers.  The key question to think about is why you should adopt a platform or a framework – and when doesn’t that make sense.

Customers today are demanding more integrated solutions.  For example, they might want to be able to create data on the web site, export it to Excel, modify it, import it back into another application or site, and then be able to visualize that data inside of Microsoft Outlook.  Even if the solutions don’t have to be integrated to the Microsoft Office suite of programs, back end integration between different systems is expected and unless you’ve got the luxury of a service oriented architecture, network service bus, and enterprise application integration tool – you may have to figure out how to integrate systems on a one-by-one basis.  That takes time and is frustrating to the users because the integration they need and expect is missing from their applications – or the time spent building the integrations seems excessive.

That’s where platforms come in.  You adopt a platform for doing some function and then build the custom parts of your solution on top of that.  You get everything the platform offers – like WebDAV support, Office Integration, a standard framework for back-end integration – but there’s a price for it.  That price is learning the platform.

Tipping Point

There’s no doubt that the more powerful the platform is the more time it will take to learn it.  The time it takes to learn the platform is the key issue to picking up any library, framework, or platform.  Complicating that is the fact that most developers – even those who are lousy at estimation – can generate a predictable end time for a solution if they’re writing all the code.  The predictability is great when you’re trying to let the business know when things will be done.

When you’re investigating platforms to see whether they’ll fit or not, there’s no guarantee that you’ll decide to use the solution you built on top of the platform.  It’s possible you’ll build 80% of the solution in an hour and struggle for the last 20% for weeks.  The framework may not even allow for a critical feature and may not work at all.

The decision is balancing a relatively known entity of developer time estimates versus a bet that the platform will deliver all of the features that you need.  Unfortunately, without engaging a platform expert, it’s hard to know at the outset whether the solution will be feasible for all the requirements or not.  For some platforms even the experts may not know whether the platform can allow for a specific feature – or if getting that feature will be easy.  Over the years I’ve been bitten numerous times by relatively simple seeming requirements being difficult to implement in a platform.

Ultimately the question comes down to: Are the benefits you get more than the price you pay to learn the platform – and the risk to the platform not working out? For narrow solutions the answer is often – it’s quicker to build what you need than learn the platform.  However, sometimes the narrow view isn’t the best long term view.

Broader Vision

If you’ve got a specific narrow problem you’re solving a good developer may be the best option.  A quick solution to process something is quicker than even evaluating potential platforms, however, many times narrow solutions grow and expand over time – or at least they would if there were an opportunity for them.  The solution that was just supposed to create a report of shipments that were damaged in transit will suddenly have to start recording information into the purchasing department so they know which shipping vendors are reliable – and which ones aren’t.

If you’re looking at partners and reporting of sales it may seem simple enough to build a web site that collects sales numbers.  However, what happens when you suddenly need to start communicating shared promotions, or you need to start tracking service requests?  Suddenly what was a narrow solution has become broader – and it’s done that very quickly.

Supporting the Solution

The other thing that a platform can sometimes give you is better support than you can afford to provide with a custom developed solution.  As new versions of the platform come out you can upgrade to take advantage of new features.  Invariably the upgrades aren’t free – even if they don’t have a direct cost – because you’ve got to retest your solution and deal with any incompatibilities that might have developed.  However, the cost of doing the upgrade is often significantly less than having to provide the capabilities yourself.

Doing the Math

It all breaks down to a simple equation:

B = Cost to Build from Scratch – Cost to Build with Platform – Cost to Learn Platform – Cost of Platform + Benefits of Platform + Upgrade Benefits

If B is positive then you’re better off building with the platform – if it’s negative it may make sense to build the solution from scratch.  The tricky bit of the equation is estimating each of the values.  The cost to build from scratch is something a developer can estimate, but the costs to build with the platform and the cost to learn the platform may not be well known.  The cost of the platform can be obtained easily enough but it’s harder to figure out how much additional value in flexibility and/or support having the platform may be – and harder still to estimate the value of being able to upgrade the platform in the future.  Despite this, putting together calibrated estimates for these are possible by engaging an expert for a short time. 

By putting the decision into the equation even with best guesses will help you feel better about deciding to use a platform or not.  In some cases, the platform is the right answer.  In other cases, it won’t be – but at least you’ll have a framework for deciding the right answer – instead of relying on what someone thinks would be more fun to do.


Tags: platform, software development




Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Sitemap | Contact Us

Rocket Fuel