My earlier blog post struck a nerve, specifically around the idea that there’s an objectively “best” thing to use to solve a problem, independent of the team and its context and its point in time. Sean Kileen also left a wonderful comment that links to a talk that says in a much better way what I’m saying.

There is a supposition at play: That independent of the knowledge I have and my team has, even taking into account our constraints (business, social, technical, financial, learning mode), there’s a better choice for us to solve a particular problem and we are hurting ourselves by not learning that choice.

And what I’m saying is this:

The team’s skill level and expertise on a toolset is probably the most important factor on whether they should choose a given tool — that all else being equal (business, social, technical, and financial constraints), that a team is better off choosing a tool they know better than a tool someone else says is better for them. Going further, I’m saying that objectively there is no best tool for the job.

There is, however, the best tool that the team feels the most confident wielding that fits into their business, social, technical, and financial constraints for the particular job they’re trying to do.

The point here is that all of these criteria are internal to a team, and you can safely disregard advice from anyone who does not have your full problem context and a full understanding of the constraints you’re under — most importantly the team’s existing knowledge and threshold for risk and learning.

The Best Framework for writing cross-platform mobile applications

When I was a VP of engineering for a startup that made a wearable; one of the earliest challenges was picking a cross-platform framework for creating mobile applications. This was a startup, and at the time, it was only me writing software. So my constraints were:

Least Time to implement
Good support for Bluetooth Low Energy
Works on Android and iOS
Good community support (in case I ran into a problem)
Good documentation
Easy finding answers on Google
Active open-source libraries
Low cost

At the time (2015), Ionic Framework fit that bill rather nicely (this was in the 1.0 days; it’s only gotten better!). Ionic had three things over your typical phonegap applications (for me):

1. There was pluggable support for BLE that was maintained by the Ionic team (“ngCordova“)
2. They had existing an entire cross-platform HTML and CSS based UI library that would allow for native Android and iOS
3. It was written to be used in Angular 1.x; which at that time I had quite a bit of experience with.

Now I should point out that I had maybe 3 years of production JavaScript experience at that point, but I had 7 years of production experience with C#, and from a generic perspective, Xamarin would have been the better choice — except for me Xamarin didn’t have #2 above that was as easy to implement as HTML and CSS were, which I had over a decade of experience with by that point.

And so I picked Ionic. For me, for that particular context, Ionic was the best choice. But think of a team with better funding and people who knew native iOS and Android development? Well native development might have been better for them, but in my case, native development would have easily added 6 months to a year for each application, which would have been catastrophic.

Now if we had had the money, the even best choice would be to outsource the application for $500,000 and call it a day. But we did not.

At the point where we were starting to be able to hire help (due to me switching to Firmware), one of the very smart candidates that literally wrote the book on React Native asked, why aren’t you using React? From this candidate’s perspective, React Native was objectively the best choice. My answer (having done the research) was that the BLE “bridge” in React Native was at the time far more nascent than the requisite ngCordova library. But, that was a decision made from my perspective. There’s also a little bit of loss-aversion at play; if you have an app 50% done, you don’t want to spend the money to rewrite it, that’s wasteful, especially if you’re a cash-strapped startup. Decisions become context. Context becomes the constraint.

Python and Django for CMS enhancements

At a rather nice company I worked for, they had an existing third-party CMS that was probably 10-15 years old at that point, and it was terrible compared to modern CMSes. Since the lifeblood of the company was financial newsletters and content marketing to sell those financial newsletters, it become a business imperative to ‘own’ the means of production. The team made the choice to move to python and Django, and write a CMS using those tools. The head of that team had played around with Python and Django, but no one had ever produced production code with it. It was a gamble from the outside looking in, but from that team’s context, it made the most sense. However, from a cultural perspective, it represented a shift in the knowledge of the company from ASP.NET and C# based tech stack (With all the requisite scaffolding and tooling built around that) to a Python based tech stack, with all the change that entailed.

To this day I’m still somewhat surprised the move occurred, but it wasn’t too long before I was brought on to a new team to make enhancements to this CMS. At the time, I had *no* python experience, and no one else on the team had python or Django experience that could help (they all had their own work to do), so I was on my own learning Django forms and controls. This made the work much harder than it needed to be for me, and I spent many weeks feeling frustrated and unable to do what I would later realize were basic things (model based forms vs template based forms yay). Ultimately the project failed from a time and budget perspective, and my future at that company was limited because of this failure.

So, was Django and Python the best tool for the team to use to build the CMS? That decision had repercussions felt years later as now developers who were never trained on or hired for Django and Python had to learn it; but outside of that team, none of us are in a situation to say the team picked the ‘best’ or ‘worst’ option; only that team, at that particular point in time, is).

If you find yourself saying “Why didn’t they use WordPress? Or SiteCore? or DotNetNuke, or Drupal”, you’re making the same mistake: We don’t have the full context and constraints that team had, and so we can’t say what would have been the ‘best’ tool for that team. Only that team can answer that question.

Rewrite or Refactor?

The final story is just that, a story, but it’s representative of what we’re talking about today. A business had made the decision to attract a new market segment, and its current software was delivered in a manner ill-suited for that new market segment, even though what it delivered was the same across segments. The team and company made the decision to start from scratch for this new segment, as there was very little expertise on the current codebase, and it was very fragile (it was having numerous production regression bugs with each release that made it difficult to be ‘stable’). Since the company had current revenue coming in for the current product, they decided they should start from scratch — with an accelerated timeline; delivering the same functionality the current system had with 1/5th of the time it took to develop originally.

Was this the ‘best’ choice? For that moment in time, with the business, political, social, financial, and cultural constraints, it was the best choice for that team. In hindsight was it the best choice? Probably not, but there would have been no way to know that at the time. That would have required knowledge the team did not have.

Bottom line

We all want to be absolved of making choices — and that is what you tend to see when someone solicits advice on what tool, language or framework they should use to accomplish a given task. They want to be absolved from the responsibility of that choice, thinking that if other people are using X, then they’ll be successful using X as well.

We also see this in conference talks, even from the best industry thought leaders. The idea that if you just use the practice, framework, tool, or language others are using, you’ll be successful. But you won’t be, or if you are, you’ll either be successful in-spite of it, or because your context and constraints didn’t hinder you.

But always, always, always, look at your contexts (Business, social, cultural, political, financial, and technical) and understand how these contexts shape your decisions, and make the decision that’s right for your team, at this point in time, with what you know right now, that fits your context and constraints.