Newsletter Issue: "Myths"

Hello everyone,

This week I'd like to cover some common myths of software projects. If you've worked with a contractor in the past, and one or all of these ring true, I hope you'll feel more prepared for success the next time around.

Even so, I can only cover so much in a brief one-page newsletter. If you have any questions at all about what I'm saying here, please hit REPLY and let me know. I'm always happy to provide more details!

Myth #1: It's Hard To Change the Software Once It's Written.

This is probably the most common myth because there's a grain of truth hidden inside. Modern software teams understand that software undergoes constant change, and design with that in mind from the start. Unfortunately, many development teams aren't versed in the latest approaches in software architecture. For them, the cost of change is directly related to the project timeline. This myth claims as the project goes along, more and more code becomes written and cemented into the product. Changing anything becomes more and more costly the deeper into the project you are. At some point, the team might seem to balk at even innocuous changes.

Let's bust this myth right now: it doesn't have to be that way. Modern approaches to software development expect change. Yes, change can incure cost, but the best teams are able to accomodate even late-breaking changes while keeping costs (i.e. time and money) to a minimum.

Be sure to ask any prospective contractor about their project methodology and how they intend to plan for the inevitable changes along the way.

Myth #2: Your Price Depends On How Long It Will Take.

I know I've yammered on about this before (see my brief blog post on Popular Contract Types if haven't already) but it's worth including here because it's one of the more common industry practices that gets under my skin. Your price should NOT depend on a wild-guess timeline estimate (and all estimates are wild guesses!), nor a time-consuming "requirements gathering" activity or "scoping exercise". Software development is not an assembly line. It is part science, part craft, part exploration, and part experiment. The number of person-hours spent on a software project is not a progress bar of completion.

Instead, your cost should be based on the software functionality that you want designed, delivered, maintained, and supported. Experienced developers should be able to price that for you without any sworn allegience to mythical hourly estimates.

Myth #3: Offshore Teams Can Deliver Software For Less.

Some folks are intrigued by low prices from offshore locations, such as India or eastern Europe. There are some wonderful software teams located in other countries that can do a great job for less than you'd spend here in the US.

But to be honest, historically speaking, that's generally not the case. Communication is transparency is paramount in software projects, and both can be a challenge when your team is on a timezone that's eleven hours away. Any perceived savings at the start quickly disappears due to chaotic meetings, requirements misunderstandings, bad assumptions, and a general misunderstanding of the problem to be solved. The resulting lack of quality can lead to a nightmare at launch time, increase maintenance costs, and sometimes lead to a complete rewrite at even more expense.

That's all for this week. If you find this issue, can you do me a favor and forward it on to someone you think might benefit? Thanks!

Got questions?
Ask me anything.

Clcik to schedule a Zoom call

Drop me an email: jeffrey@softwareforresearch.com

Find me on Twitter (DMs are open): @jeffcohen