Casinos are a place of pure excitement — each visit an exercise in frenzied fun. The short-lived thrill of a large payout is tough to beat. But then, it's over. Better luck next time. Who could possibly enjoy forfeiting their money like this? Sure, you have great earning potential, but the odds are simply not in your favor.
Gambling, casinos, compulsive habits — software? Yes. And it's easier than you think to make ludicrous decisions during the development of software products. Do they seem out to lunch at the time? Of course not. You're a good developer with common sense. You've toured the neighborhood and have street smarts. And yet, you still make bets that aren't in your favor.
The Big Picture
The largest bet we place on our software projects is whether we do the project at all. What we're setting out to do, to sell, and to solve — this is by far the riskiest job. At inception, there is no product. There's no project either. Because, at this point, everything is still just an idea. At this stage, we're still outside of the casino doors.
Jumping from inception to real projects is the ultimate dice roll. Here, a bold statement is made. We will deliver the best open source project management system. We will turn around this customer portal in six months. We will sell enough of this video editing software to stay alive for the next six months. A gamble is only a gamble because we've set a goal. A tangible to aim for. Without a goal, it cannot be missed — and so you've nothing to lose.
This, in my mind, begs the question — are we better off not setting goals for software projects in the first place? Could we better operate as a software development team if the bar is lowered, if the threat of failure is eliminated? Of course, lowering the pressure — delivering production-ready code fast — endows a degree of competitiveness. Without predefined goals, and conversely, consequences of not meeting those goals, we're more inclined to make the right decisions during the development effort. More focus is targeted at product design. We can evaluate alternatives, something that all too often evaporates in the face of pressure to deliver a sound product or service.
Is there a need to make big-picture gambles? Are there any rewards to setting goals and trying to exceed them? Or should we assume a passive attitude and simply do the right thing in terms of what we, the developers, think is right? The trouble is, not setting a tone — a sense of urgency on the project will ultimately dilute the pace of progress. How can you measure progress if you haven't a target to aim for?
Gambling Versus Guessing
I would argue that the big picture gamble — the decision to build and to solve and to move forward — is inevitable. The truth is, there is no such thing as safe software development with no risk because humans are responsible for building it. Humans are living organisms who only have so much time to devote — there are only 24 hours in a day. We build software because of an insatiable urge to build things. Not random things, but functional tools that serve a purpose and are of appreciable value. Is the software, when finished, going to be of relevance — to yourself or to anyone else? This is a gamble that is unavoidable — it's sown into the fabric of writing code.
The trouble for me, is, how do you know what makes a great software product? What really stands out above and beyond anything else? There is obviously something that makes this a reality for software projects because success stories are plentiful. But they do pale in comparison to failed software development efforts. These failed for there own unique reasons. There wasn't enough consumer adoption. There wasn't enough funding to support the continued development. The list goes on, but I do think there is one dimension shared between those that succeed and those that do not.
Gambling in software development terms isn't exactly the same as gambling in casinos. If you're hitting a slot machine, you've no control over the outcome. This is a pure gamble, win or lose. We're guessing that we'll win. Software development at least gives us some indicators — the kind that can assist with making informed, calculated decisions before we place our bets. This is better than guessing.
So to avoid becoming a statistic in favor of not starting a software project due to likelihood of failure, it's best to limit guessing. Guessing that something will just work. Guessing that your potential customers have a real need for your product and will applaud it. Guessing that using library abc over library xyz will be beneficial. These are all things that we can research and deliberate over. Not doing so means you're guessing, and doing so will lead to diminished control over the direction of your project. Sure, both successful and unsuccessful software projects make big gambles. Some win, and win big, others, not so much. But the ones who win big undoubtedly restrain the amount of guesswork — much more so than their counterparts.
No comments :
Post a Comment