Give Your Software Project A Chance At Success

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).

Problem Complexity

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.

Technological Choices

Your solution lies somewhere between assembly and a JavaScript framework that is being written as your read this post (I’m looking at you Node).  I can almost guarantee it  =]

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.

One red is quite ambitious.  Dare I say, adventurous?  Sounds like fun, sign me up!

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!

Advertisements

Joke: Three Envelopes

A man had just been hired as the new CEO of a large corporation. The CEO who was stepping down did a private exit interview and presented him with three numbered envelopes. “Open these up if you run into any major problems,” said the ex-CEO as he ran out the door.

Well, things were going quite well for a while, but a few months later, business started slowing down.  At his wit’s end, the new CEO remembered the envelopes. He went to his desk drawer and took out the first envelope. The letter read, “Blame your predecessor.”

The new CEO tactfully blamed the previous CEO. Satisfied with his comments, Wall Street responded positively, sales began to pick up, and the first big problem was solved.

A few months later, the company was again experiencing more sales problems. Having learned from the last time, the CEO opened the second envelope. The message read, “Reorganize.”  Wall Street was once again kind.

After a few consecutive profitable quarters, the company again was having problems. The CEO went to his office and opened the third envelope.

The message read, “Prepare three envelopes.”

A Programmer’s Most Important Job

Many years ago when I was starting out in the world of technology consulting, I was having a conversation with one of my mentors, and he pulled me aside and asked me a rhetorical question: “Fernando, what have you done today to bring $1,200 worth of value to Client X’s business? That is what the client is asking themselves right now, so make every day impactful.”

No One Pays You to Code

I have been developing software for money for almost 17 years and no business executive has ever said to me anything along the lines of: “Your code is REALLY good.  I just love your use of prototypical inheritance!”  Some of you are probably thinking: “That’s because this guy’s code probably sucks. I get that compliment twice a week.”  Be that as it may, business executives don’t really care about the code.  Read that last sentence again.  Out loud.  Make it your desktop background.  Tattoo it on your forehead.  They care about what the software does for the users.  No value for users = whogivesacrap.  Value is relative and varied, but has nothing to do with the software itself, but rather what the software does.  Value can be making money, saving money, entertainment, saving time, cleaning your dining room floor (thank you Roomba), heating your food (hey, microwaves are software too), etc.

I am not suggesting that great code has no value.  It does.  It has tremendous value.  Software that can quickly and easily be modified to generate value for users is worth much more than the cost of creating it.  Great code is easy to modify and bend to your will.  As a corollary, the teams that build valuable software efficiently, are highly prized.

But no one actually pays you to code, they pay you to generate value for their users.  You just happen to code.  If businesses could generate value by sacrificing goats, you’d be in your cubicle right now, wearing an apron, sharpening your knives, wondering when your next goat will be arriving.

Help Your Business

So how do you provide your-yearly-salary-divided-by-the-number-of-days-that-you-work dollars worth of value every?  You try to make your business more successful every day.  How do you do that?  Help the business make decisions that lead to the most benefit for the least cost, and then build it.

At one job, the product owner wanted to mix our invite-a-friend functionality with some gamification concepts.  To build out this feature, it would have taken about three weeks of design and coding.  The team’s counteroffer was to manually email all our users, let them know what they would get if they invited some friends, and tweak our existing invite-a-friend functionality to upgrade members who invited friends.  New timeframe: 3-5 days.  Guess which option the business went with?

We could have built what the product owner wanted, but that would have meant that we couldn’t work on other site features that were also really important (always be thinking about opportunity cost).  So instead of just giving them the bad news, we spent time brainstorming other ideas that might generate similar value for a much smaller investment of our time/money.

In most businesses, you have a fixed amount of money/time/resources to generate value for your customers.  Typically, the value generated from any one feature is unknown, and since you don’t know how well something will work before you try it, you should really be thoughtful when you are investing a relatively large amount of resources on a single feature.  That said, you do have to make some big investments from time to time to build something compelling.  I will write another entire blog post on cost/benefit analysis since this skill is more art than science, and I’ve run across many teams that do a poor job of choosing where to over/under-invest.  In the meantime, work hard with people in your company to help the team make the right tradeoffs.