Myth & Reality In Software Development

Daily, we engage with our software development clients to launch products their customers love. But as anyone involved in software development can relate, Builders, there are a lot of mythical expectations out there around what software developers can actually do in reality. Additionally, we've heard from potential Builders across our social media channels about their ideas of what software development should or could be. But what can you actually expect from the software development process? Today, we'll explore just that.Much of the mythology around software development stems from the user experience itself. As technology moves into the seamless territory of “magic” in the mind of end users, so does mythology around the development process increase. Software developers become wizards, who can solve any problem with the wave of a wand. As any developer can tell you, this is not the case. Effective developers (like the 75,000 technical and creative resources we have access to in our Capacity Partner network) and an effective development process is both systematic and responsive--but never magical.Dissuading magical thinking around development and managing expectations makes the process easier for client and developer alike, ensuring that all stakeholders are satisfied in the long-term. Curious to separate the myth from reality, Builders? Read on.

Myth #1: Development fixes everything

No. Full stop. If the expectation upfront is that a solution will be the end-all, be-all solution to end all solutions, a project is on the straight road to disaster. Nip this one in the bud right away. Assert that all technology evolves and will continue to evolve and encourage holistic thinking around software as “solution.” Creative and continued review of your product will constantly develop your product. Your MVP launch should be just the beginning.

Myth #2: It’s a process you can completely plan for

It’s understood in business that when money is on the line there needs to be a plan in place. That being said, all partners in the development process need to understand development is not simply an assembly line (more on this below.) Planning can of course happen, but it has to be done in a way that leaves room for contingencies that can (and will) happen along the way. Static budget and static timeline and static anything is an unrealistic expectation. Prepare for this by being crystal clear with your product features in three particular areas, namely:

Must have (Read: I've gotta have it!)
Would like to have (Read: I'd really, really like to have this)
Would be nice to have (Read: It'd be good to have this feature, but I don't absolutely need to ship an MVP with this feature)

When communicating about anything that could be perceived as static (i.e. timeline or estimates) be sure to provide complete context that includes assumptions and risks. As a project moves forward, make sure that you continue to engage stakeholders by checking in on their assumptions and goals.

Myth #3: A giant team is the best team

Another significant myth about development that complicates the process unnecessarily is the idea that a bigger team is a better team, or that adding new members to a team mid-development will somehow speed up the process. Consider it (and explain it) in this way— software development is not a mechanical process. In traditional, mechanical production as one might see on the assembly line, plugging in a new body (read: a new technical resource for example) to replicate a step naturally increases production. Not so in software development. Nuances and details in onboarding a new contributor can, in fact, delay production even further. If new bodies are needed, understand that onboarding may take time away from production and plan accordingly.

Myth #4: It’s a fast process

It can be. It's not always. Effective communication (see above) will address this pain point in the process. As stumbling blocks present—or, ideally, if you see them coming down the pipeline—address them with open-ended questions that engage stakeholders and contributors. Their engagement can make slowdowns seem like times of production, but more importantly, keep a team on track and closer to schedule.

Myth #5: Release is the end goal

Release is a step, not the end goal. Development is an iterative process. The technologies themselves are iterative and defined by constant and ongoing development and fluctuations. Is reaching a release date satisfying? Yes. Is it the end of the process? Not by a long shot. If the expectation is that a release date is the end of the process, stakeholders will be only setting themselves up for frustration. In early stages, define post-release and management as an ongoing conversation with end users that will only improve the product, and make sure that all stakeholders understand the long game.Mythologizing may be an asset in some fields, but it tends to complicate things when it comes to software development. How have you navigated around myths in this space, Builders? Chime in on Facebook, Twitter, LinkedIn and Instagram. And make sure to explore our own bit of “magic” by visiting Builder Studio.