Good, Fast or Cheap - Pick Two

Product Selection for Architects

 
A friend of mine was a construction contractor and his customer mantra was simple:
 
“I can build it good, fast, and cheap.  Pick 2.”
 
You’ve probably heard that before, and of course it applies whether you’re building a house or a cloud native application.  The hard part is picking which two criteria are most important for you, and knowing which criteria is expendable.  For my contractor friend, if the customer picked fast and cheap his mantra to the construction crew became “it doesn’t look perfect, but it will look fine from the next job site.”
 
For developers, there is no shortage of tools and SaaS/PaaS products to help them build.  I started thinking about how difficult it must be to sort through the available options and select a product that you will essentially be married to for months or years, and the difficulty of balancing quality, performance, and cost.
 
To get some perspective, I sat down with our Chief Architect to pick his brain about the vendor selection process.  In the enterprise space, many product decisions regarding commodity technology are about “good and cheap” – or at least good enough.  To put it another way it is about comparing value to price and finding an acceptable compromise.  In the developer space, there are other nuances.
 

The Price is Not the True Cost

 
One of the big takeaways from the conversation is that cost is measured in different terms by developer organizations.  We typically think of cost in terms of licensing, supporting infrastructure, or monthly SaaS charges.  As Durga pointed out, it isn’t quite so straightforward for a dev shop.
 
“Obviously the first selection criteria is ‘can it handle my workload.’  Sometimes the workload itself narrows the field down to just one or two products that can accomplish the task.  An example requirement we’re familiar with would be a database that is consistent across a dozen global regions.  A hosted NoSQL or cloud platform that can only replicate across 6 locations may be more common, but if I truly needed more locations or a global footprint, then Macrometa would be the right platform.”
 
This is where the conversation became even more interesting.  I asked if there were multiple products that fit the workload needs, how would he narrow down the options and make a final selection?
 
“The most important thing is the cost – but not in terms of the actual product pricing.  Unless the cost is vastly different, the monthly or one-time expense isn’t enough to influence a decision.  I evaluate products based upon my most important costs – Time.”
 
This made a lot of sense to me.  If Product A is $500 and Product B is $700, but Product B will let me produce my product (an app) 50% faster, then the additional time to market savings greatly offset the additional expense.  Tying up 10 developers for 2 months is better than committing 10 developers for 4 months – not to mention the loss of use or revenue impact of unnecessarily delaying an application release.
 
“The second most important element is simplicity and ease of use.  This is also a major contributor to the true cost in time, since it is faster to leverage existing expertise on the team without having to learn new skills.  The same is true for customer support.  If we run into issues, it is imperative that the solution be well-documented and that help is readily available.”
 
Macrometa shines in the time to value category.  Providing a ready made, geo-distributed, global data network (GDN) that can serve as a cloud backend across 100s of locations means that a developer's time can now be 100% focused on getting code completed and products shipped.  If you’re interested in seeing just how easy it is to accelerate your development cycle with Macrometa and your team’s existing coding skills, just click the button below and create a free developer account. 
 
Sign Up For A Free Account