Developers Have a Gambling Problem — Here’s How To Fix It

Zack Minott

Stop chasing jackpots. Casino thinking can impact your codebases

Photo by Michał Parzuchowski on Unsplash.

You probably don’t realize it, but you have a gambling problem.

Don’t worry. It’s not your fault. You weren’t intentional about it. After all, development as a whole is commonly flawed in the sense that it’s approached like a gamble.

You’re betting on the success of each feature that you build. You’re working under the assumption that what you’re building will provide value of sorts. That it’ll make life easier for others. That it’ll make your life easier. You’re not always aware of the outcome of what you’re building, and there’s no way you can be. But you still think that it will output some positive effect.

So you go on about your day, spending months building out a project, feature after feature, while betting wildly on success without any evidence or tell-tale sign that it will succeed.

Each feature is a bet. The whole project is a casino. And you’re the sucker chasing down that mythical jackpot.

This way of thinking is the very reason why projects fail. Why features never see the light of day. Why the outcome won’t be what you expect it to be. Why hard work and great minds go to waste.

Any project that is backed by this thinking is doomed to fail from the start.

You’re not a fortune teller. You don’t have a crystal ball telling you that everything will go as planned.

Perhaps you’re thinking I’m talking nonsense. That development has to be a gamble. There’s no other way to know if something would work unless you build it out… right?

Unfortunately, that statement historically doesn’t hold true. 68% of IT projects are labeled as “improbable” and 56% of technology projects deliver less value than predicted for this very reason.

To slap you in the face with another statistic, 17% of projects go so bad that they threaten the very existence of a company.

This only covers companies that are established. There’s a whole other spectrum of failure to evaluate for those “developreneurs” and app builders out there that we simply never hear about.

Still not convinced? Well here’s a story that might change your mind.

(Hard Work + Optimism + Flawless Design != Project Success) => True

There’s this online marketplace that serves as a medium for artists and hobbyists to put their self-made products up for sale.

The development team thought it’d be a great idea to convert their product directory’s pagination feature to that of infinite scrolling. The idea behind why they were doing this was simple: If a user can endlessly scroll through an entire list of products, more products would capture their attention and this would therefore cause them to buy more.

Sounds like it’d work… right? I mean the infinite scrolling features of social media allow us to have an infinite amount of attention-stealing content to consume. So why shouldn’t it work for online sellers too?

So, with this in mind, the team invested a heavy amount of time (a few months) building out this feature and restructuring the user interface so that their redesign can accommodate this feature.

Lo and behold, months later, they rolled out the new feature just to find out that *insert dramatic pause here* user feedback was negative and resulted in a decreased turnover rate despite their expectations that it’d produce positive growth. Months of work and thousands of dollars down the drain just to find out that this catastrophic failure would be tossed in the wastebasket.

They expected success and spent an immense amount of energy and time just to be met with the grim face of disappointment.

This was among the biggest failures that Etsy has ever faced. Despite that being so, Etsy’s CEO said that this was the most important mistake they’ve ever made.

It led the company to reevaluate the way they approach new features and ultimately led them down the path to becoming the most profitable and productive they’ve ever been as a company.

They merely recognized the powerful lesson hidden in their mistake.

It doesn’t matter what your vision is, how flawlessly you design something, or how much energy and focus you put into your work. The blood, sweat, tears, and gusto you put into your implementation don’t inherently reflect its value.

You can’t predict how your target audience will react to your product, so you must do what you can early on to prove that what you’re building will work.

You need to increase certainty.

The Key Needed To Increase the Probability of a Winning Hand

There exists a pressing pre-assumption that infects the developer’s mind when first kicking off their project implementation. The best way I can think of conveying this mindset to you is simply by presenting this question: Are you building a feature because it will provide value or because you think it will provide value?

Many of you — and I, for that matter — tend to pursue a project simply because of the latter. That you think it will provide value. You don’t know it will.

You’re going in blind. You embark on this grand journey for weeks, months, or years even just to reach the very end and find that it was all for naught. Going all-in on a bet with unknown probabilities. You need to raise your odds of playing a winning hand.

See, developers tend to put a heavy emphasis on the need to optimize for performance, speed, and scale. All are very important. Unfortunately, they tend to fall short on the one thing that’s most important: whether or not what you are building is truly needed.

In order to answer this question, you must take your problem and solution, and smash it into bits and pieces of “testable hypotheses.”

In other words, apply scientific theory and the Socratic method by taking an experiment-driven approach to development. Experiment-driven design is a method used to validate the success of your project. It increases the range of certainty.

By adopting this method, you’re no longer merely gambling. You’re playing your hand like a professional poker player using strategy, probability, and validation as the driving force behind your decisions.

To make this work, you need to first ask yourself how you might expend 10% of your effort up front to validate that your project will work.

You can think of this similarly to a minimal viable product where the expected value you create is the hypothesis. Normally, developers approach a singular path towards a solution by building out the entire product or feature without first validating the solution. With this method, you put a heavy emphasis on experimentation.

Instead of approaching the creation of value in one way, you instead try a plethora of different strategies, run A/B tests against small groups of non-biased users, and compare the small results of each strategy against one another. By deeply evaluating each experimental hypothesis early and often, you’re able to extract great confidence in what works and what doesn’t.

When you run an experimental test that works and promises high potential for the turnover rate that you yearn for, it gives you more confidence that whatever path you’re treading on is in fact the right and most valuable one.

If you incrementally validate each assumption, you’ll find yourself with the leverage you need to create the most long-term impact without too much risk. You’ll allow yourself to lower your probability of failure and heighten your probability of success.

Play Your Cards Right

I know you want to just put your head down and immediately start writing the best code that you can possibly imagine, but there’s no need to be in such a rush.

I get it: You want to reach a deadline. You want to satisfy the client. You want to present a whole and ready product. You want to generate value as fast as you can. You want to build out the dream app sooner rather than later. So you just dive straight into things without looking at both sides of the road, just to get sidewinded by a car.

It doesn’t need to be that way. Experiment-driven design is a very simple and easy strategy to implement in your daily workflow.

For instance, as a developer consultant, I have many different projects that I work on across several different companies. One thing that’s made me successful so far is not delivering as fast as possible (though that helps) but keeping the client engaged and involved throughout the entire process. I aim to satisfy the client by building out a small piece of the pie that they’re asking for and reaching out for their input the entirety of the way. This way, I’m able to consistently gather information on what will provide them the most value.

I highly suggest you do the same. Build out a small part of a feature and present that to others. Show your manager. Show your fellow developers. Show coworkers who aren’t within the IT department. Show friends what you’ve got done and see how they react.

The point is you need to constantly be gathering data to work with. With that data, you can better refine the goals of your project and the way you go about achieving those goals.

This way, instead of having one go at innovation, you’re constantly innovating the whole time. You create the potential for more and more value based on the data you receive. From here, you transform your simple gamble into a confident, tried-and-true strategy with a high probability of success.

Comments / 0

Published by

Cloud Developer | Philosopher | Avid Reader | Intellectual Explorer and Lifelong Learner | Athlete | Top Writer @Medium

Santa Ana, CA

More from Zack Minott

Comments / 0