The Last Mile

Road – ♀Μøỳαл_Bгεлл♂

If you ask a developer which part of a project he finds most challenging you’ll probably get answers like “requirements gathering” or “architecture”.  In my experience the most difficult part of a project is always the final 10%.  You have the vast majority of your application done.  The client has seen nearly if not every feature he asked for, but now you’re at the point where the rubber really meets the road and anything that might have been the least bit vague or nebulous is in the forefront.  Usually this is where the developer starts to cry “scope creep!” and the client will start to talk about what they really meant when they said they wanted that button to glow or that view to flip.  This is the point where just as you feel you start to see the light at the end of the tunnel there’s some new issue in the tracker that you thought you and your client agreed on but now there’s some contention.

I’d like to present a few strategies that might be helpful during those final trying days (weeks?):

1. Use a good tracker – It’s important to have a running list of the items that need to be completed, those that have been delivered and signed off on, and also a list of bugs in your project.  Pivotal Tracker is a great product for this.  It used to be free, but now costs $7 / month for its base plan.  If you don’t want to pay for Pivotal, you can always use a free product like Bugzilla to handle your needs or even a shared Google spreadsheet can work in a pinch.
2. Have a change process built in – Your contract should have provisions built-in for handling items not clearly specified in your requirements.  There are several schools of thought in handling change.  You could simply add more time and cost for your client, or alternatively encourage your client to drop some other piece of equal or greater complexity to make room for their alteration (making them choose what’s really important).  Either it’s important that both parties understand what should happen as these instances will certainly occur in nearly any project.
3. Create the punch-out list –  Sit down with your client and his requirements and clearly plan out the remaining work to be done and attempt to flesh out any open questions.  Consider this like renewing marriage vows.  Nothing’s changing, you’re simply agreeing to “re-agree”.  As you proceed with the final 10% of your project items on your list should crossed off.  Once the list is done, the project is done.
4. Get a good list of requirements up front – It seems obvious, but I know most developers have been in the situation where requirements are too vague or just plain missing.  As a developer you don’t really know what you’re building and the client doesn’t really know what he should be expecting.  Regardless, you and your client certainly aren’t going to agree on the project.  There are two types of requirements you have to be aware of:
• Functional – What does your project do?  What should the user be able to accomplish using your application?  These can take many forms: use cases, user stories.  Sometimes they’re told thru wireframes or mockups.  These tell you the “what” of your application.
• Non-Functional – Functional requirements tell you what.  Non-functional requirements tell you how.  Do you have to adhere to a certain set of branding guidelines?  Does a view need to pull data from a database in under 2 seconds?  Should that view transition via a UINavigationController or should it appear modally?  These are the most overlooked requirements.  It’s a common story that a developer is told what an app should do (the what) and told to go to town.  Sometimes the most time-consuming parts of an application are tied up here.

The number one rule is to be up-front with your client about time and budget.  Most clients in my experience aren’t out there to screw their developers (though some are), but it’s important to understand that your interests as the developer and your client’s are in some ways diametrically opposed:  He wants the most bang for his buck, and you ultimately want to find the most efficient path to completion.  Never is this more apparent than during that last mile project.

What do you think?  How do you work with clients to push that final 10%?

How much for that iPhone App?

I don’t know how it is I haven’t come across this stackoverflow discussion about iPhone app costs before.

Like most developers, I’m asked frequently to run levels of estimate for software projects at work and in the freelance arena. Consistently, I feel like there’s pressure to give the client a number that they can swallow, which is ordinarily way under what the work is at a quality level I’m comfortable with. It’s a constant battle for me to be honest with myself about the time required to actually complete the work. After all, everyone loves to get the contract.

Of course, the downside is, and everyone knows it, that a gross under-bid is bad for everyone. As the developer, you feel overly constrained to meet unrealistic deadlines, you wind up putting in hours for free or feel like you’re not serving your clients as well as you can by delivering a sub-par product.

The discussion is an excellent read for folks who always find themselves having to place numbers on iOS projects. It’s refreshing to get a peek into the scales of production from the developers of some the most revered apps out there.