Note: this was a past topic in the newsletter and I've reproduced it here, mostly unchanged.

---

It's been said that "it's easier to learn than to unlearn." I encounter this sometimes when speaking with researchers who have had a less-than-stellar past experience with a software development firm. Beliefs formed from a bad experience become calcified and make it harder to work with a new team the next time around.

Here are three popular misconceptions that come up often.

Myth #1: It's Hard To Change 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: The 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.