How not to get ripped off by your iPhone developer, Part 2: Include Milestones in your RFPs

“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.

So I’m writing 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. The first post is about why it costs so much to clean these up. This post, our topic is:

“Is there anything I can do in my Request For Proposal to increase my odds of avoiding bad developers?”

But, before we get started, first a disclaimer. I am not an impartial observer (and I don’t even play one on TV). I have a vested interest in what I’m about to say, and it’s influenced by my background and opinions. I am going to say some things that people are going to get pissed off about. I am okay with that. If you aren’t, then you should probably find something else to read.

Disclaimer two, the way I’m recommending is not necessarily the cheapest way. If you go with the cheapest developer you can find and you get lucky, you will definitely spend less money than if you follow my advice. But if you don’t get lucky, and have to have it done over again, it can end up costing you far more than your initial estimate.

RFP Technique 1: Require Milestones and Signoffs

I would recommend that you never let your developer go more than about 2 weeks or 20% of your project budget (in time or money), whichever is shorter, without giving you a new build with new functionality and release notes. So if it’s a 10 day project, you should get a new build and release notes every 48 hours or so. If it’s a six month project, you should get 12 or 13 new builds with release notes over the course of the project, at least 2 each month. Each one should have new stuff in it (although the UI might not always be different).

I would also recommend that you require your potential vendors to break the project down into that many individual steps up front and write them down on their proposal. If they can’t tell you up front what the milestones are going to be, how likely do you think they’ll be to have guessed correctly about time and budget?

Now it’s not unlikely that one of those milestones might be late (or the direction of the project may change and ). That’s not necessarily the end of the world. But wouldn’t you rather know and have that conversation with your developer at that point than the day before you think they’re supposed to be done?

Now this is more work for the developer, and they’re not going to like it. They’re going to tell you it’s more work (and it is) and it’s going to cost you more (and it is). But it reduces your risk, and you have to decide what your risk is worth to you.

Also, don’t let the developer save the hard stuff until the end of the project.

Have the developer tell you what the hardest part(s) are going to be for them. And then ask them how they can move those items as soon in the schedule as possible. Maybe the first build you get doesn’t look like your App at all, but has one screen with one big button that says “Upload big data file to server”. You push it, and then you go look at the server and make sure the file showed up. That might be okay.

A lot of projects are done this way: Money to developer up front, followed by the first milestone of a UI mockup that doesn’t do anything but look kinda pretty (at which point the developer gets more money), followed by several weeks while they “work on the backend stuff” (background processing, talking to servers, facebook, etc, etc). At which point you get what’s supposed to be the final build and it works or not.

It’s not that mockups aren’t important, they are, but most idiots can build a mockup and if not, there are a ton of Apps developers can buy that almost do it for them. Mockups are not a point of risk. You don’t need to check the status of things that are really easy. You need lots of milestones in the middle of the parts that can actually go badly.

Then if you see things starting to slip, you’ll know as soon as you can. And there are an entire category of developers that won’t even bother to bid on that kind of project, because they don’t like people looking over their shoulders. Those people you probably don’t want.

And if the project does go badly and you have to pull the plug, hopefully you can pull the plug earlier rather than later, and you have some documentation about what the developer was doing and thinking and planning, which will help (at least some) in the event you have to call someone else to bail you out.

Thank you for reading, and I hoped you found this post useful.

Please check back soon, and read the next post in the series, which is about Why bad iPhone developers don’t like RFPs that require test code.

How Not to Get Ripped off by your iPhone Developer, Part 1: Costs and Cleanup

“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.