“I have an iPhone App that another developer built for me, and it’s 90% of the way there, but that developer is no longer available and I just need someone to do the last 10%.”

I got that call again recently (it seems to happen every month or two). And this time, as almost every time, it turns out they weren’t even close to 90% done.

Although I have paid my mortgage more than one month by cleaning up after another developer, I hate those situations. The client has almost always spent all (or nearly all) of their allocated budget, and they have almost always been led to believe that they were very close to being done. But in fact, even the best developer in the world couldn’t take the pile of code they currently have and make it into what they wanted by their desired release date. And worse, there’s no way any developer could make a living by being paid only what was left over after some charlatan took half the budget up front and wasted their time.

So I’m going to write a series of post about this situation, what your options are if you find yourself in it, and what you can do to avoid it in the first place. This post, our topic is:

“Why would it cost as much (or more) to finish this App that almost works than the amount I was quoted to develop it in the first place?”

Well, I know it can seem counter-intuitive, but usually bad code is worse than no code at all. And even good code that you’ve never seen before can take as long or longer to figure out than it would have to start over from scratch.

We’re going to talk about Bad Code and the Bad Programmers that Write It in my next post, but for now, let me explain that, even if the code that exists really is 90% done (and trust me, it’s not, but that’s another post), that it would still take the new guy you hired significantly more time and money than the 10% you have left.

That seems impossible to a lot of people that I talk to. I think that’s because a lot of people who don’t write code for a living think of software as being made up of more or less interchangeable blocks. A lot of people think of programming like construction. They think there must be the equivalent of two-by-fours and bricks and sheet rock.

They expect that if the guy painting your house gets sick and he wasn’t intentionally trying to rip them off, any other housepainter can tell immediately where the new paint is and what hasn’t been painted yet, open up the unused cans of paint and finish in roughly the same amount of additional time that the first guy said it would take.

And virtually everyone knows that when they call someone to change out the appliances and cabinets in their kitchen that it shouldn’t cost 80–120% of the market value of the entire house.

So what’s the disconnect here?

First, let’s start with an analogy

Let’s say you walk into a restaurant and the restaurant owner immediately grabs you and drags you into the kitchen. There’s something sizzling in a pan on one of the burners, a pot bubbling away on another one and something roasting in the oven. You are told “we have a banquet starting in two hours and our cook just quit, can you just finish this up real quick?”

You don’t have the recipe that the original cook was working from, just the description of the item from the menu and, if you’re lucky, a picture of the finished dish from a restaurant brochure. You open the drawer where you keep your kitchen utensils so you can grab a spoon and try to taste what’s in the pot so that maybe you can guess whether it’s supposed to be a soup course or the sauce, but that drawer is full of placemats and napkin rings. You start looking in other drawers and cabinets, but nothing is in any organizational pattern you can determine. The knives all have tiny handles because the previous cook apparently had much smaller hands than you, and the spatulas and tongs are all three times longer than you have at home, because the previous cook apparently had much shorter arms than you.

You might be able to imagine an expert chef (which I’m not) quickly taking inventory of the drawers and cupboards, carefully tasting each thing that’s cooking, guessing at what was yet to be done, working around the differences in the utensils and getting something completed and out to the diners.

But you can also, I hope, imagine an expert chef in that situation running (or sending someone) next door to the store to grab the ingredients and utensils that they use dozens of times every day, starting over, and putting together a dish much like one they’ve cooked before from a base recipe they have made many, many times, and just adjusting the flavors and presentation to match the description from the menu.

Which of those dishes is more likely to taste better? Which of those dishes is more likely to have a mistake made that causes it to be inedible? Which is more likely to be confidently and safely served to a diner that turns out at the last minute to be violently allergic to peanuts (or some other ingredient)?

While admittedly not a perfect analogy, there are definitely some similarities between programming and cooking. And I certainly find that people are generally more familiar with the process of food being made than the process of software being made.

The secret sauce (so to speak)

So, here’s the thing about developers in general – we save time by reusing the same techniques and code that we’ve used before. Some piece of functionality that could take 3 weeks for “the average programmer” (if there is such a beast) might only take me 5 minutes – if I already spent 3 weeks writing it on my last project and I still have the code lying around and I can just drop it in. Likewise a single line of Unity3D code that would take a competent Unity3D programmer 2 seconds to drop in could take me weeks to figure out – because I’ve never written an Unity3D program in my life, and I’d have to read a book or something to even know where to start.

As a matter of fact, it’s so common for programmers to reuse the same techniques over and over that some smart people wrote a bunch of them down and coined the phrase “ Design Patterns” and wrote a book about it. And it’s so common that the book sold a bunch of copies, and generated a bunch of spinoffs (I think I have six different variants of “ Programming Language Design Patterns” or “Design Patterns in Programming Language” books in my office).

But when we developers are asked to take over a project already in progress, we don’t get to use our favorite techniques. We don’t get to grab our most weathered recipe card from where it stays pinned to the refrigerator with a magnet and just get to work. Instead, we have to taste everything that’s already cooking and try to figure out what the other guy was thinking. And that’s a lot of work, and takes a long time (and it’s as much fun as sorting someone else’s underwear drawer). And worst of all, it’s error prone – sometimes we guess wrong, and don’t realize it until we already started down a path, and then we have to reverse course, wasting time and money (yours and ours).

And then, well, then there are the other cases. You see, ummm…

Some developers…

Well…

They just aren’t any good. And some of them are worse than just not any good.

And this post has already gone on too long.

So come back soon, and read the next post in the series, which is about How to avoid hiring bad iPhone developers .