Custom software development is a lot of things, but you’d be hard pressed to find a way to describe it as “easy”.
It takes a lot of planning and resources. Often you need a team to make it happen. Technology is changing at an incredible rate, so you need to get serious about adopting a methodology too.
There’s risks and rewards and, like everything else, you celebrate the wins and learn from the mistakes.
But one of the things experienced in all areas of software development, from business owners to junior developers and everyone in between, is the nagging, gut-wrenching feeling of uncertainty.
Sometimes it hits you in a coding sprint or maybe in the middle of a planning meeting. Maybe it even keeps you up at night as you’re reflecting on the day.
Regardless of when or how it happens, everyone who’s ever written a line of code, planned a project, documented a feature or implemented a process has asked the question:
“Am I doing this right?”
Whether you realize it or not, that moment of clarity is worth some serious reflection. It’s a big deal.
It’s a moment worth unpacking because it’s really three separate, important things all wrapped into one package:
- It’s an honest admission of a real concern.
- It’s a question that actually answers itself, the answer is 99% of the time being a resounding ‘No’.
- It’s a simple realization of an opportunity disguised as a challenge.
So often, an individual or company’s reaction to uncertainty can define the path forward, whether it be in the direction of progress or regression. And it’s in no way a task handled simply.
But the good news is that uncertainty in building software isn’t rare.
In fact, the issues you come across, regardless of how specific they may sound, have more than likely been experienced by countless others before you.
You’re not alone in struggling with code challenges -- far from it.
Countless companies have struggled with updating production as often as they’d like, however frequently. Getting the beta version of an app launched is tough for everyone, and version 1 is probably tougher.
Because after all, custom software development is a battle and uncertainty manifests itself in all kinds of interesting ways.
Whether developed by an outside vendor or derived in-house, custom software tools become the weapons businesses use to battle their competition in a daily struggle for revenue and mindshare on a highly contentious field of operations.
And while comparing business to battle might be a little dramatic, it’s not that far of a stretch to draw military comparisons to those involved in custom software development.
Software developers often serve as the first line of defense in the battle for progress, solving problems with an ever increasing arsenal of programming languages that are rapidly evolving. It’s a highly fluid situation with lots of pressure and responsibility because the features you deliver today will make a difference in the product tomorrow.
Working in this fast paced, results driven environment can place engineers in a position of great uncertainty. Sometimes code is written when the problem isn’t fully realized, which can result in technical debt. Or sometimes developers wear different hats and deal with infrastructure issues and maintain security for the network.
The “It’s-Not-My-Job-But-I’ll-Do-It-Anyway” nature of being a developer in a small business environment can lead to all kinds of uncertain decisions that had to be made just to get through the day.
Then there are project owners that are trying to organize the battle and make everything run fluidly, like an eight-armed organization machine built to communicate, plan, execute and succeed. Project managers face uncertainty every day and have to make quick decisions that can lead to unpredictable outcomes.
Finally, there’s business owners who act as the Generals of the battle.
They’re not necessarily concerned with the inner workings of the system, they just want the updates to flow and the features delivered on time. They want things to work like they are supposed to work because progress is tied to revenue. It’s simple. Uncertainty around progress means posing some highest risk questions:
Is the app going to crash? Do I have enough resources to tackle the issue? Am I doing this right?
Time and time again, people facing uncertainty in software development spend a lot of time considering the problem, white-boarding thoughts on the matter and after struggling to frame up the problem, admit defeat and move on.
Again, this makes total sense because cutting through the uncertainty is hard work.
Reaching an epiphany that shines a light through the darkness is tough business. Unfortunately, there are plenty of paths that help people take to avoid dealing with uncertainty.
Ambitious business owners are, by definition, driven to excel and reach new heights. Oftentimes, leveling up a business is tied to enhancing software tools.
The bounds of this improvement process, the point A to point B type stuff, the start- and end-view of things, are probably pretty clear.
The uncertainty lies in how to get from here to there. It can be hard to figure out just how to define the change that needs to happen to reach the goal.
And that’s when people fall into the trap of filling the uncertainty gap with a healthy dose of “what’s always worked”. To succeed, sometimes companies try to continually do the same things over and over and expect different results.
One of the most valuable lessons learned is the thing that brought forth success in one venture won’t necessarily be the tools to bring success in another. Or, as Marshall Goldsmith says in his popular book, what got you here -- the success you’ve had up until now -- isn’t going to get you there.
Instead of facing uncertainty with old ways, it’s time to acknowledge what you don’t know and find some alternatives.
Another way people deal with uncertainty is simply ignoring that it exists and forging ahead in the interest of getting things done. Handling uncertainty this way has all types of unintended consequences at all different levels.
Software developers spend a ton of time wading through uncertainty in the search for a solution to a problem. And oftentimes, they implement solutions and get things done just to reach a deadline, all the while carrying around with the nagging suspicion that “ something just doesn’t feel right.”
Without proper guidance, communication and teamwork, developers find themselves awash in uncertainty and, through no fault of their own, deliver a solution to a problem that isn’t quite as elegant as needed.
Technical debt is defined as the accumulation of time and effort needed to fix previous work that was completed to achieve an end, such as release date or hot fix. It’s like real debt in that it exists, must be addressed, and can be negative. According to a recent study, companies spent over \$85 billion dealing with technical debt in 2018 alone.
Tech debt isn’t just accumulated by developers though. Far from it.
Tech debt can be incurred when project requirements shift, scope creeps, and things change, causing the original direction of a venture to be altered and swift adjustments to be implemented to reach a quick deadline.
Technical debt is just one side effect of ignoring uncertainty. Another thing is downtime. Every website on the Internet seemingly has a story of going down at one point or another because someone just “tried to do something,” despite a healthy dose of uncertainty.
Progressing forward without addressing uncertainty compounds issues and leads to impacts feature releases. Product upgrades become harder and disaster recovery takes longer.
To restate the original point, custom software development is tough. When a company reaches a point where the next level up is in sight but the path forward is unclear, it’s easy to choose the worst option, which is to do nothing.
And again, this makes perfect sense because it’s not in the nature of all companies to be good at developing software.
Said another way, it’s absolutely true that companies need software to thrive and survive in the modern world. But that doesn’t mean you have to be an expert at making software.
It would be like requiring you to map out every part of an automobile’s engine as a requirement for a driver’s license. The idea is absurd -- that’s the very reason why auto mechanics exist. The same argument applies to networking, websites, and custom software development.
Companies struggle with software development because software development is hard.
Large organizations have a tough time maintaining the safety of their networks because cybersecurity is an inherently difficult task to figure out.
Development teams falter in implementing DevOps strategies because the concept is difficult to handle without years of experience.
The uncertainty around complex ideas in software development is inherently difficult but the rewards associated with overcoming the unknown can be great.
One of the benefits derived from dealing with uncertainty is it naturally causes companies to admit it’s unclear on how to deal with something. The act of acknowledging uncertainty in any activity kicks off a domino effect that inevitably leads to reflection.
Posing the question “Are we doing this correctly?” naturally leads to the analysis of the process. And more often than not, you’re going to find that the act of asking the question itself is all the evidence needed to provide the answer that things could in fact be better.
One option to dealing uncertainty is to tackle the challenge head on, similar to how streaming content provider Netflix approached the situation.
Netflix handled the uncertainty of faults in the system by creating a tool that would purposefully create an environment of chaos for it’s developers. The Netflix-created tool, named Chaos Monkey, operates in all their systems' environments, causing chaos by randomly shutting down server instances and triggering errors, thus forcing developers to anticipate outages as they constantly work with unreliable services.
This environment, coupled with Netflix’s adoption of a strict DevOps development protocol, produces a seamless end user experience and provides “developers a unique opportunity to test their software in unexpected failure conditions, but incentivizes them to build fault-tolerant systems to make their day-to-day job as developers less frustrating.”
Another option is to pair with a trusted advisor in your space to handle the situation. Many partnerships formed in uncertain situations have led to successful transitions to the next level. In this case, do some homework, ask a lot of questions, and find a way through the fog.