Losing Religion
How MustWin Weighs Our Tech
We like to think of ourselves as “technology agnostic” at Must Win. All too often a programmer’s career is defined by the flavor-of-the-week tools they adopt. Suddenly they are “the Ruby on Rails expert” and in order to preserve and elevate their own position they become evangelists, they write posts about why their tool is better than the others, they fight about it on twitter, they attend conferences where other similarly minded people preach at each other reinforcing how smart they are for being a #{hot_new_technology} purist.
The meme for blind faith secures its own perpetuation by the simple unconscious expedient of discouraging rational inquiry.” — Richard Dawkins, The Selfish Gene
Avoiding religion
Engineers, like scientists, need to be basing their decisions on facts, not religion. We have to be more than Python people, Ruby people, Node people, Go people, Angular people, etc. Good engineers know and understand the tradeoffs between the tools they use, and they choose what will work best for the goals of their project (be they for technical, financial, political or other justifiable reasons.) Over the next few weeks we’ll be sharing the ups and downs of many of our favorite technologies and when we think they best suit our needs.
Tradeoff costs
Life is a series of tradeoffs, and none of us get out of it alive.
—Anonymous Coward, PsychologyToday.com
Every major technical decision (and most of the minor ones) involves tradeoffs. Typically these tradeoffs transpose three currencies: Time, Money, and Scope. Most also involve giving and taking other significant functional things too, but we’ll cover those in technology specific posts later. The tradeoffs between these major categories are pretty intuitive. If you add scope, it adds time which typically means more money too. Sometimes you can save yourself time by spending more money, etc. All these categories are supported by other driving forces, depicted below.
Scope
Scope is what most people think about first when it comes to building products. That makes sense, since it’s the impetus for everything else. Elements of Scope can be broken down into some helpful sub-categories. Business requirements is the most helpful when discussing tradeoffs, because it tends to drive a lot of choices. For instance, if your system needs 9 9s of uptime, maybe it makes sense to invent Erlang to support that endeavor. Requirements add to scope, which also adds to time and money, so it could be the case that doing that is too expensive, so it doesn’t make sense to invest in that. Other contributors are product features, which in theory drive revenue (decreasing the monetary cost side of the equation). Then there are other non-revenue driving product goals. These could be things that provide indirect value like analysis tools, Konami codes, several extra redesigns, or whatever.
Time
The total time commitment = (time to acquire the staff you need + time for said staff to complete the scope — your productivity gains). This is where a lot of developers spend their time proselytizing. Vim or Emacs, Ruby or Python, MySQL or Postgresql, Rails or Node! Admittedly, your choice of tools can make a huge difference, so not all these arguments are inane. Languages that are more expressive offer initial productivity gains that can significantly accelerate project timelines, just as compiled languages that run more efficiently can lower operation costs.
Money
Money — Profit really, is the most interesting metric in these decisions because, in most cases, it’s the underlying motivation for everything else that happens in this diagram. Maximizing profits (over some period of time) is the point of this optimization problem. Driving revenues (or lowering costs) by meeting business requirements and adding competitive features is why most software organizations exist.
Money also adds some flexibility to your time scale. Often, you can buy things much faster than you could create them yourself. You can (sometimes) hire more staff to improve your concurrency. The tools you choose can also affect your operations expenditures. Running 100s of ruby servers is much more expensive than running 10 java servers.
Balancing it all
Every decision you make as an engineer affects these categories for your project. And often we’re completely unaware of the magnitude of the little decisions we make every day. Someone else will be dealing with the consequences years from now, so it’s easy not to give it much thought. Great engineers will understand these tradeoffs and try to be cognizant of the consequences to the project.
How MustWin decides
MustWin tends to optimize for delivering the maximum scope in the shortest time given a fixed budget. All of those nobs are adjustable, but this tends to be how our clients want things done, so we’ve structured our technology choices around that setup. This means that we tend to make choices that maximize our output, even at the possible expense of other things. So we choose tools for these criteria:
Effectiveness
This is always the first criteria because it trumps the others. Tools we choose need to actually solve the problem at hand. Not to name names, but if we run a transaction oriented business, choosing a database that supports transactions is the right choice. Often these choices are less binary, like with application frameworks.
Expertise
How well you can wield a tool is directly proportional to your productivity with it. A hefty learning curve is therefore off-putting, and we try not to go too far off the beaten path with whatever the latest testing DSL (or whatever) is, because learning new ones every week is an epic waste of everyone’s time.
Expressiveness
Because
puts 'Hello world'is way easier than
class HelloWorld
{
public static void main(String args[])
{
System.out.println("Hello World");
}
}Yes, I realize that’s simplistic. Yes, we use java for things. It’s still true.
Ecosystem
We also choose tools that have mature ecosystems. The prevalence of open source software means that most basic problems are solved in mature ecosystems. To build a web app today I don’t have to build my own user authentication engine, reimplement oauth2, or write smtp clients. I would have to do those things in a new ecosystem, and that would probably be a waste of our clients’ money.
This is the first post in a series about our goto technology choices, why we made them, and what we love/hate about them. Expect us to dive into specific technologies in future posts.
Want to hear more about our specific technology tradeoffs? Join our mailing list for an update when my next post goes live.
Mike Ihbe is a founding partner ofThe Must Win All Star Web & Mobile Consultancy.
Mike is an expert in a dizzying array of technologies and has loads of experience managing fast-moving dev teams, designing systems, and scaling large applications. When not on the job, he can be found cooking delicious meals on ski slopes in exotic locales.
