The Truth About Software Development (It's Non-linear And Imperfect)

I’m sitting in my favorite seat at a Lakers game, mowing a pretzel and a paloma, watching Lebron James and Anthony Davis work their magic. 

Bill Macdonald and Stu Lantz are bantering back and forth, I just spotted Adele sitting a few rows ahead of me, and we’re winning - life is good. 

But then something happens - someone stumbles and twists an ankle, someone gets distracted by Adele and misses the pass. Shit happens.

Then we’re down to the buzzer and it’s up to LeBron to sink that 3 pointer and win this.

And even though LeBron has been playing basketball for 25+ years, even though he’s one of the best players basketball has ever seen, even though he makes the basket MUCH MORE OFTEN than he doesn’t … this time he misses.

Is it a bit disappointing? Yes. Is it also the reality of the game? Also yes.

And I’d like to take this moment to draw a parallel between my beloved Lakers and developing software.

Just like pretty much every area of life, business, and sports - “success” in software is non-linear.

7 hard truths about software development and tech entrepreneurship here

(Honestly, this is the article I wish someone had sent me as a bright-eyed, bushy-tailed 20-something, throwing myself into the world of tech entrepreneurship. If you know someone who’s interested in launching their very first app - please consider forwarding this to them and take a look at the way we do MV(S)P’s differently with the Neutech Wave. You could save them so much stress and time! And if you’re ready to get your app developed, we’d love to help! You can grab a spot on my calendar here.)

Hard Truth 1: Scaling isn’t just a matter of multiplying your code

Wouldn’t it be cool if the Lakers could clone LeBron and just have 26 LeBrons running around the court? Regrettably for all of us, that’s not possible.

Similarly, it seems like if an app works well for 100 users, it should work equally well for 1,000 people. Shouldn’t it just be a matter of scaling up the lambdas? It’s not.

And often, the only way to discover if an app is truly scalable is to … scale it. We make our best bet, draw on our years of experience, call in our top 1% Master Builders - and sometimes we discover that we need a different approach to solve your use case.

Success is not always predictable; sometimes you have to learn by doing.

And to be clear, these scaling issues aren’t necessarily because your development team doesn’t know what they’re doing. It might be because your specific product, in your specific market, needs to scale in a different way.

For example, if you’re a medical company,  something may not scale correctly because the HIPAA compliant Medicare API has a rate limiter. So you can't ingest data as quickly because of how a HIPAA compliant API may behave.

Or another company may have millions of records in a database that need to be scanned through and your development team needs to create a solution to ingest and present data really fast.

In either of these cases, your development team might approach these issues the first time using “the usual” approaches - things that work 90% of the time! - only to discover they need to try something new.

Just because “the usual” approach didn’t work doesn’t mean you have a “bad” development team.

Hard Truth 2: Coding isn’t “one and done”

Can you imagine Darvin Ham (RIP) telling Rui Hachimura to practice his hook shot ONE TIME and then being like “Looks good”??!

Of course not.

Starting a software company is a journey; it’s an ongoing process that will require tweaks and changes as your company changes. 

You will have to get comfortable continuously investing in your code, and growing your code base and feature set in line with discovering and expanding product market fit.

When you bring your MVSP to market, you’ll probably discover that users particularly love a specific feature - so you’ll need new code to expand that feature.

And when you launch the new version after you’ve expanded that feature, you might find hundreds of thousands of new users. And you’ll need new code to scale to meet the needs of all those new users.

And when your app has been on the market for a few years and you get a bit of competition - competition who has a bunch of flashy updates you don’t have - well, you’ll need new code for that, too.

The same way the Lakers are regularly practicing, conditioning, upgrading their gear to stay on top of their game, any successful software company should expect to invest in code in an ongoing way.

Want to know more learned-the-hard-way insights into tech entrepreneurship? You can read the whole blog post here.