How to Pick a Software Stack

When starting a new company or project, one of the most daunting phases is selecting a stack. There are lots of things that factor into the decision, and anyone who has done this before will attest that you will make some bad choices, and some of those will be nearly impossible to undo, especially if you’re successful. Some questions to consider:

What do you already know/love/hate?

When considering your options for some piece of the stack, it is totally reasonable to award points to things you know and love, and deduct points from things you know and hate. It is, however, not a good idea for this to be the principal factor. You should be able to defend your favorite choice against the others objectively and quantitatively, not solely on the basis of “it feels better” or “I know it already”.

Are you just trying to execute a business/goal or are you trying to explore and learn something new?

One of my two virtues of engineering is curiosity. Throughout your career, you should always be looking for opportunities to explore new ideas, new tools, new methods. If this is some moonlight or passion project, actively try to weight new and unfamiliar things higher. If this is a major venture with lots of other people’s time and money, there is just as much to be gained from leveraging your experience and going for flawless execution of things you’ve already worked out the kinks on.

If you have teammates, what do they know/love/hate?

This is a case where you should set the hierarchy aside and try to get everyone’s opinion. If you’re a senior engineer or architect you can bring experience to the table but don’t discount the novel approaches and backgrounds of your teammates, regardless of their experience. We so often get stuck in our ways, even after only a few years, and avoid novelty and diversity in the name of risk.

Are you going to need to hire/outsource the work?

If your plan involves getting dozens or hundreds of people on board in the near future, you’re going to want to lean to the more popular/vanilla options. Trying to hire 300 people in the next 12 months to work on your Erlang/Neo4J stack running on an Arduino cluster is going to be much harder than getting people to do Java/MySQL on AWS.

Are you building a prototype, an MVP, or a “real” version.

Deciding, and more importantly understanding what you’re building is a topic worth exploring on it’s own, but roughly speaking you’re building one of three things:

The Prototype

You just need to get something “working” to explain your idea or your solution. Unless you’re doing something truly revolutionary (p99.999 confidence spoiler alert: you aren’t), try to prototype your idea/business/product OR your technology, not both at the same time. Also really commit to throwing this away and starting over with a proper plan if there is promise. I’ve seen/had too many prototypes turn into projects that have a pile of technical debt before they even really start.

The MVP

I feel the MVP is overused, and too often is an excuse for a poor quality product or a starved team/budget. You obviously want to iterate, and if you want to call your first release an MVP for buzzword sake, go ahead, but don’t write throwaway code unless you’re committed to throwing it away (see prototype above). I’ve lost count of the number of companies and projects I’ve talked to that are rewriting their Rails or Django app because those seemed like easier paths to an MVP and “now we just need to scale”. That’s like saying “I’m going to get a job, but then I’m going to go and get a completely different job that actually pays my bills.”

If you are truly building an MVP, then your process for stack selection is no different than building the real version, it’s just prioritized more aggressively.

The “Real” Version

The first step here is to figure out, as best as you and your team can, what the successful (often AKA profitable) version of your app/system looks like. Do you need 100 users to break even? Do you need a million? If you need a million, don’t spend a single minute building something that only works for hundreds. If you need 100, don’t spend any time building it for 1 billion (unless you get that for no additional work, E.G. something like Amazon S3).

What features are truly required to hit that goal? Make sure there is a place for them in your architecture even if you don’t plan to build them right away. Do you need support and sales teams to be successful? Make sure you’re putting hooks in for the tools they will need (E.G. CRM, ticketing, admin consoles).

What can you get “for free”?

Everything has a cost, in terms of time, money, people, etc. but those costs are not always the same across companies and projects. Your team’s experience can discount learning curves, your company may already have investments or licenses for things. Never use something just because it’s free, but make sure that is a part of your decision.

If you’re at a larger organization with a number of teams, consider if there is a team supporting certain aspects of what you might use. If there is a logging system that is in place and ready to go and has its own support, it’s should be a hard sell to build or buy or set up a new one just because of a few features. Often that team will even build what you need!

What are your competitors using?

Competitive analysis can be difficult, most software companies don’t go too deep on what they are using for any given situation, but that information can play a large part in your decision. If you find a conference talk where they talk about what they tried and had good or bad results from, you’ve possibly just saved yourself a lot of pain. You will often just get a lot of good ideas (“I never considered using X to do Y”), or pointers to things you’ve never heard of.

You might also find some competitive advantage. If they are using something you know is difficult to change or won’t scale well, make sure yours can beat them in those aspects. By the time they realize you’re about to pass them it might be too late for them to adjust.

What will fail first?

As you’re building your stack, know where the weak points are, and don’t be shy about circulating that information. If you can’t get to your target latency because some component will use 90% of that budget, try to find a replacement early rather than assuming you can plug something else in later. You should be confident that all of your core components can hit your targets, and if you aren’t sure, validate that now. You’ll find that the interconnected nature of systems will often lead you to replacing more than one piece at a time, which only makes it less like you’ll be able to do it, and more likely to fail.

What else?

Picking a stack is harder, and takes more time, than most people realize. I’m sure there are other things to consider and I’ve love to hear your thoughts on this in the comments.

Software Side Project/Business Checklist

So you’ve got an idea. Maybe The Idea. You need to do it, and you need to start now, maybe you already did. Here is a list of things to do, or at least keep in mind before you get too far. They mostly won’t slow you down, but in the event your project actually takes off, I guarantee this will pay off in the long run in terms of saving money and time and avoiding hassle and heartbreak.

Many of these steps (especially the early ones) apply to any business or project, but my experience lies mostly in software so this list is tailored to that.

Note: This is a living post, in that I intend to come back and update it when there is more to add, so be sure to bookmark it somewhere!

Step 0: Clear It!

If you are a knowledge worker or work for a company big enough to have HR or lawyers, you probably had to sign something when you got hired that assigns ownership of inventions/copyright/patents/etc. to the company while you are an employee there. If your thing ever becomes valuable, that will matter. Do not rely solely on the fact that your state has laws about this or that you think management is reasonable. Write up your idea in a reasonable amount of detail and get a waiver in writing from the company. Most good employers will have no problem with this if it’s not related to their interest and the better employers will even encourage this as a way for you to grow and hopefully bring some energy and new experiences back to your job.

Do not do anything until you have this in place. Don’t write code, don’t register domains, don’t collaborate with others about business models, nothing that could come back and see your efforts snatched in a lawsuit. The bigger your company, the more important this is as they have broader interests and more lawyers.

Step 1: Name It

Names have power. If your idea doesn’t have a name, it will struggle for attention and likely wither away. Your name doesn’t have to be permanent, you can give it a codename, but name it something.

Domains

If you think this might turn into a real thing someday, align your name with your domain. It doesn’t have to be a perfect match, but close enough. Even if you’re not planning on building a website (e.g. an app, etsy store, etc.), you’re likely to build one eventually or at least want an email address for it.

If you can’t get the .com domain because a possible competitor has it, pick a new name, not a different TLD (e.g. .net, .io, etc.)

Codenames

Codenames have a knack for survival. They will be around in some form for the life of your project, in documents, emails, code comments, and so on. Don’t call your new project something embarrassing or offensive because “we’ll change it later”. You’re better off picking something meaningless and common like “Green Tea” or “Fortitude” if you can’t come up with something better.

Social Media

Once you’ve got a name and a domain, set up whatever social media accounts/pages/handles you think are relevant. They don’t have to be perfect matches, but the closer the better. You don’t want someone else to do it for you, as it can be impossible or expensive to get it back.

Step 2: Register It

If you’re in the US, and you think your project will generate any revenue or expenses this year, you’re better off to get it set up as a business as soon as possible. It’s pretty easy and cheap to do so.

If you’re doing this with other people, you’ll want to set up a partnership/LLC/Corporation. Even if it’s family, get this taken care of now to avoid tears later.

If you’re doing this by yourself, go to your city/town hall and register as a DBA. There generally isn’t a penalty for not doing this, but it may come in handy later when setting up things like bank accounts or making commitments like contracts or commitments.

Once your entity exists, go get a tax ID. As a sole proprietor this isn’t required, but it’s free to do it and will keep things better separated down the line.

More to Come…

I’ll add more to this list later, but if you can get those steps above done before you invest too much, you can proceed with far more confidence that you’re not forgetting something important.

TV in 2015

I think most people, including myself sometimes, watch too much TV, but I don’t think the right amount of TV is zero.  We really are in a golden age for the artform and with the putrefaction of the film industry, I don’t think there’s anything wrong with enjoying it in limited quantities.  My thoughts on some current and recent shows:

American Ninja Warrior

This show has been on for a while but I had never even attempted to watch it because it has a terrible name.  I caught part of an episode last year and realized it was not some campy parody of a Japanese game show but something else entirely.  If you’re not familiar, it is a relatively simple concept.  Contestants run an obstacle course with the primary goal being to finish the course and the secondary goal being time.  The twist here is that the course is incredibly hard.  Most people fail.  They don’t get any practice and if they make one mistake they are done.  In this age of coddling and positive reinforcement this show takes us back to the days when video games didn’t have save files, when the 10th best hitter on the baseball team rode the bench all season, and cars would explode in minor accidents if they didn’t impale you on the steering wheel first.  It reminds us how satisfying hard work can be and there is no doubt that the frustration and happiness of the contestants is real.

Hannibal

Recently cancelled, hopefully to be picked up elsewhere, I am surprised it even made it this far.  It is a very dark, very deliberate, very long story.  The imagery, music, and sounds are often vague and pretentious, but they are always detailed and highly crafted if not beautiful.  And with all due respect to Anthony Hopkins, Mads Mikkelsen is amazing as Hannibal Lecter.  I recently watched a bit of Silence of the Lambs and Hopkins’ take on the role is almost clownish.

Halt and Catch Fire

A couples romance where the main conflict driver is entrepreneurship.  The show captures what feels like a very authentic bleakness about 1980’s Texas.  After two seasons, the writing has become a bit aimless but the characters are authentic and the acting is very good.

Mr. Robot

This show is brand new, but the pilot was amazing.  If someone said they were going to do a mashup of Dexter and Fight Club and maybe throw a teeny bit of Sherlock Holmes (Elementary-style) in, I don’t know what I’d expect but this show pulls that off.  The pilot could have easily been tweaked into a good movie and is one of the best I’ve ever seen.  The rest of season one was not as good but more sustainable, and has maintained the thriller aspect.  Christian Slater is television poison, but he has a limited role that doesn’t leverage his usually hamminess, so we’ll see if the curse can be reversed here.

Reasonable Design

I’m always trying new productivity/task/project software, in the hope that someone will write the one I need before I do.  The latest one is Action Method, by Behance.  It’s not very useful to people with more than a handful of tasks (i.e. everyone), but that’s not the purpose of this post.  After failing to find it’s value, I read through the FAQ and found this gem:

Why are there only 3 colors for my Action Steps?

We thought about including more colors. But then one of our early Beta  testers said it best: “If 3 colors are enough to safely drive a car  [traffic lights], they should be enough to organize  yourself.” (Thanks, Jordan!) Sometimes, simplicity is best.

This is a terrible way to design software, and an even more terrible way to explain it to users.  Driving a car has nothing to do with accomplishing or organizing your workload.  Not even in a “well now that I think of it” way, it’s just plain irrelevant.   If that’s your reasoning, why aren’t the colors red, green, and yellow (they are blue, orange and gray)? Should all of the buttons on the site be round because the wheels are round?  Should all of the text be white on green because that’s good enough for highway signage?

I’m being silly here, but the point is that when you have to make a decision like this, be mindful of the reasoning behind it.  Rationalizing an arbitrary choice with a trite and irrelevant explanation might sound cute, and it’s a standard design cop-out, so avoid it.  Perhaps 3 colors is the right answer here, which could be for any number of valid reasons:

  • 90% of people never use all 3.
  • User testing showed that 3 was easier than 5 or 7 or 16 million.
  • It’s an intentional design goal that colors don’t proliferate because people end up confusing themselves on advanced projects.
  • It looks ugly (I’m guessing this is the actual reason)

Or maybe, since this is in the frequently asked questions, 3 isn’t the right answer at all, regardless of traffic engineering standards.