Very recently, a colleague forwarded me a link to Pick Your Battles, a story I’ve seen play out many times before. I am not a fortune teller by any stretch, but I knew the plot after the second paragraph. It’s a great read, and if you haven’t read it, you probably should.
I’ve built all types of software (consumer, business, mobile, embedded, and more) with different types of teams (internal, all consultants, offshore, and blends) and over time I found three factors that could pre-determine failure (but not necessarily success).
In software, building blogging software is much easier than writing software to land a satellite on something in outer space. Blogging is a relatively straight-forward concept, whereas landing hunks of metal on celestial bodies that are traveling at almost 55,000 miles per hour sounds really hard. I would speculate that knowing what the solution looks like before you start helps you to focus on the high-risk areas, validate assumptions, and test carefully. However, given complicated problems, even the best minds will make mistakes. Just ask NASA about going to foreign planets or even our moon. Using some common sense, feel free to rate your problem complexity using a simple red, yellow, or green color indicator where green is blogging and red is going to another planet.
Assuming that you have a Problem Complexity level of “green” or “yellow”, why would you choose to throw some gasoline on your grill when you are just trying to toast some hamburger buns (read: more risk)? Java, .NET, PHP, and a relational database are all good enough for _almost_ any business. However, if you have the type of sustenance problem that requires a flame thrower and some napalm, you might want to start looking at some other solutions (I’m looking at you Scala and NoSQL). Since decisions are rarely made in a vacuum, depending on your Problem Complexity, choose a tech stack that makes sense and unless you can explain why you should NOT go with a modern-day Blub Language, you should start blubin’ it up. Give yourself a green color indicator on this factor if you chose a technology that is older than the iPhone 3G (2008ish) _AND_ Craigslist gets multiple posts per day on said technology. Otherwise, you get a red color indicator.
Team That Will Build It
Given the first couple of factors, Problem Complexity and Tech Choices, picking a color indicator for this one should be easy. You get a green color indicator if your team has solved the problem before and is expert on your tech choices. Yellow if they have one of the two aforementioned qualities. Red otherwise.
A Close Fourth Factor: Team That Will Maintain It
I know that I said that there were three factors, but since around 60% of the costs of software is in maintenance, this one deserves a mention. Another factor to consider if the team that maintains the software is different from the team that originally built the software.
Good to Go?
If you have all greens, then congratulations, you are solving problems that have been solved before, with technologies that are well known, with _the_ team that solved them. Your existence is no longer necessary, and you all can safely be replaced by robots.
Two or three reds and you should probably re-evaluate your positions and carefully track your progress to see if you are making any. Unless you are really good at predicting the future, your project will probably run into some BIG unexpected issues (in my mind these unexpected issues should be expected). If you aren’t in a position to re-evaluate some of your choices, then you might consider letting the main stakeholders know about your concerns. As a backup plan, start preparing three envelopes. Good luck!