Rapture In Venice’s Development Process

September 17, 2010 John Blanco Uncategorized

I’ve worked with small companies and large, startups and huge corporations, and in addition to working as an independent consultant I’ve formulated my own personal software process that I’d like to think is a nice mix of all the best features of what I’ve experienced before and imagined on my own. And so I’d like to share it with you.

My Philosophy

My process is a lightweight process overall, but includes elements many might consider part of a more “structured” methodology. Most notably, while I’m a huge Agile advocate, dealing with change simply must be considered a reality in software production, I also believe in upfront design and documentation. When working with 90% of the clients I’ve worked with, documentation (of varying sorts) is simply necessary to get the job done, and I don’t think it’s realistic (or desirable) to be working with the client directly on a daily basis and calling that “being agile.” It simply doesn’t work and you can’t rely on the client having time to chat with a developer.

Pre-Production

The first thing I do is meet with the client, discuss at a high-level what they’re looking to have done, and if I feel I can solve their problem I give them a very rough, general price range for what it will take to get it done. I usually stick to a fairly sizable price range to try to avoid any surprises, but there’ve been a couple instances where the final contract ended up a little higher, or even a little lower, than the estimate.

If the client wants to move forward, a user research period begins where I might do any of the following:

• Determine what technology should be used to solve the problem.
• Gather up resources to get it done, from software to humans (perhaps a designer).
• Get agreement on a time schedule for getting things done.

That last part, creating a rough schedule, is important for me. I’m not a full-time consultant, I’m part-time. So, I have to get agreement from a client that the app they want in one week might take three weeks. The clients I work with are those that have smaller tasks or, themselves, are undertaking the project part-time. It’s just an agreement that needs to be made.

The next step is what I dub “The Summit.” I like to get everyone involved with the project in a room, in person, and talking requirements. This is where platforms and technology are hashed out, but we also discuss what the app will do. Often times a server developer is involved and it’s good to make sure they’re on board now rather than later! Also, I like to talk about the app screen by screen, it helps to get people focused on what they want the app to convey and look like, and unless you’re working for a large software maker, there’s no need to keep requirements TOO high level that you can’t talk about specific screens. There’s also the benefit that clients are always talking more specifically about how the app should look and trying to keep them away from that level of abstraction is likely not to be received with pleasure!

After this discussion, and any followups that may be needed to hash out additional details, I create the initial functional specification. This document lists out everything the app will do based on the requirements and additional ideation. It includes algorithms, how complex fields are formed, and anything that I would need to tell *another* developer to get the job done. In the Agile community this is often ignored and it’s a HUGE mistake. If you’ve ever written software and found you often didn’t know what each screen was supposed to display or how it was supposed to behave, and you had to keep going back to the client for more and more information throughout the ENTIRE project, you are probably missing a functional spec.

The spec doesn’t mean change can’t happen. Change ALWAYS happens. The difference is that when change happens, you update the spec! It should always reflect how the app is supposed to work. The reason is that ad hoc discussions between developer and client don’t do anything to help everyone else who needs to know how the app works: project managers, designers, marketing, and especially testers!

Another thing. The spec should be created by you and not the client. If the client creates one, you can use it as a basis for your own, but in general the client’s spec will not include the details you need to get your job done. Software is about details. That’s why the technical person should be in charge of the spec!

The spec and the SOW (Statement of Work) are submitted to the client, iterated on, and signed off. Next, to steal a term from Joel Spolsky, it’s time for Butts-In-Seat. GO!

Butts-In-Seat

With research done and spec in hand, implementation begins. There should be no questions about payment or what the client wants at this point. Your butt is at your desk and you are writing code. In theory, you should be able to go long spans of time without needing to speak to the client if it comes to that. In general, I like to give clients daily updates during the “buildout” phase. I call the time between when the app is started (File/New Project) and when there’s minimal functionality enough to actually be able to run the thing (My tweets are being retrieved!) as buildout.

Once buildout is complete, I focus on adding in all the functionality, fixing bugs along the way, until I get to a functionally complete Alpha product. Alpha is usually a small phase which basically means fixing any show-stopper issues that prevent the client from seeing ALL of the functionality. At that point, it’s Beta and we go into a full-time testing cycle.

Testing

Testing involves using the app, verifying the app, and making sure it matches the spec. During testing is when you’ll also see a lot of change. Now that the client can use the app like a real user would, they (and you) will notice user experiences that simply don’t work well. I’m usually very liberal with clients when it comes to change of this matter.

When it comes to new functionality, however, I am sure to be very strict on the matter. What I like to do is add the new feature requests to a list that we can come back to when testing is done. At that time, we negotiate what features I’m willing to add for free, but which will require additional cost. At this point, another SOW may be called for, but it’s never an iterable thing. The app has to be released after all and the client is eager for that to happen.

Post-Production

As a mobile developer, post-production entails taking care of the release to the Apple Store (or Android Market, etc.) for the client. Any major bugs that are reported early get folded into a point release that I like to have pushed to the users sometimes just a mere few days after release. With so many devices to mind over (yes, even with iOS these days), there’s usually some hiccup at the beginning. No company is immune, so just accept reality and be prepared for it. :-)

I hope this little discussion of my process has been helpful!

Is an Objective-C Minifier Possible? Overriding Your iPhone’s Localization In-App