Buying Software Development Services Is a Skill

Don't believe the software development myths. Read on to learn why.

There are gems for this

This happens all the time. We’re approached by people working on their startups, people who are fighting to build the product. Occasionally they have some software development know-how, maybe not coming directly from writing own code, but from working closely with developers. “But you know, there are gems for this, it should be a quick one” - they say.

This is one of the biggest lies about software development you can hear these days. That development has become much faster and cheaper than it used to be. Because Ruby on Rails. Because gems. Because themes. Fantastic world of insta-coding.

Let me tell you the truth. Heart transplant is not easier and quicker just because all the necessary parts and tools are there. You still need time, preparation and a team of experts to get it done.

Software development takes time. Software needs love. Otherwise you end up with a huge technological debt and there’s no one waiting out there to bail you out.

We are delayed, we need more developers

It’s an absolute classic. Development’s not going with the desired pace? Let’s add more developers! It doesn’t work.

The bearing of a child takes nine months, no matter how many women are assigned.

It's a famous quote from Fred Brooks. And it’s true.

Many things cause software development delays. And this quote is even more true when it comes to developing software for startups. Because these ultracool frameworks are unstable and have bugs which take days to fix. Development tools are not mature or just broken. Sure, everything looks great in the “Todo list” tutorial, but the reality is hell.

Trying to speed up things by adding more developers is just a wrong cure. Team size is not the source of the problem. All you can do as a product owner is to be patient (but don’t forget about Parkinson’s law).

Can you estimate this?

Another one. “I wanna build Uber for dog walkers. It should have similar features. Can you send me an estimate?”

No, we can’t. Or maybe we can, yes, it’s 2 gazzzzzzilioooon dollars. But seriously, there are two types of projects: ones you can estimate and ones you can’t.

The ones you actually can estimate usually have well defined scope and will be build with stable frameworks. I say usually because in software development everything can change just because of one tiny non-standard requirement. But for the sake of this post let’s assume that it’s true for well defined scope and stable, well-documented dev stack.

If you’re planning to use Meteor and have problems with defining what exactly you want to build, requiring an estimate is just unrealistic. Been there done that. If we don’t know what features will land in the Backlog, how are we supposed to know how long it’ll take to develop them?

Other factors making it harder to estimate:

• Developers using given technology for the first time

• Working with a code base written by someone else

Oh, and one more thing: don’t believe your developer friends. They always do it, they say it’s simple and should take one day. They lie.