Industry Veterain Samuel Moshe discusses the what prototyping is, and why no app project should go without one.
Last night, I was on the phone with a client who is very excited about their new cloud app. She was absolutely thrilled that we’re going to be able to get the project done on time, and for less money than anybody else was able to quote her. It’s what we do.
What she had trouble understanding was the prototyping process. It’s not her fault. A lot of people who don’t do cloud software for a living simply don’t understand how these things work, and part of the job is education.
So the first question to answer is, what is a prototype?
Now, it’s fair the point out that not everybody does this, but we do, as part of the process. Prototyping keeps the cost of the app low and eliminates confusion, which saves you a ton of money and keeps you from getting frustrated. Piece of mind is difficult to put a price on, but we try to make sure it’s included in all of our projects.
Most good developers build prototypes and/or functional mockups before they start a project. If you go into a project without one, there’s really no good way for everyone to understand what the functional requirements are… no matter how well you’ve written them out.
A prototype is a throw away application that essentially does what the final application will be expected to. As a rule, you forgo things like the look and feel, and focus on the functional elements of your design. It’ll use the same database, and/or logical structures you set up for the final application, it’ll give you a feel for how the usage process works, and most importantly… it gives you something you can touch and understand at the beginning of the software development process, rather than the end.
The prototyping phase of the project is where you scrutinize things like usability, process, your feature set, and workflow of the app. It’s where you can work out the kinks in the application, and solve the problem of scope creep, where “wouldn’t it be nice if…” can turn into weeks of additional work.
Once you’ve got everything you need from the process, you can lock down the requirement, get consensus from the stake holders, and really make sure that everyone involved understands what you intend to build. Then, you take a note of the workflow and the queries you used to make the prototype happen.
Ideally, the next step is to throw away all the prototype code, and never think about it again.
And, as a general rule… that’s where I lose people. A question I get often goes something like this:
“Yes, but Sammy, why would you want to write the app twice? You just spent all this time writing a system that works. Why on earth would you want to throw it all away and do the same thing all over again?”
Well, my astute theoretical client, I’m glad you asked.
The key thing to remember about a prototype is that it’s prototype quality code. It’s written the quickest possible way, using tools you’re unlikely to ever use to build the final product. The idea is to spend as little time as is humanly possible to build complex functional code.
If you were going to think of a cloud app like a movie, the prototype would be the storyboard, or the screen test.
The purpose of it is to get sign off and really build an understanding with both the client and the developer, as to what is going to be created, nothing more.
A real app is going to need some thought put into security, maintenance, manageability, and a truck load of other things that are deal makers and breakers in a live app, are generally not thought about at all in the prototyping phases of production.
And that’s why you hear developers and programmers use terms like “production quality code.” Production quality is a finished product, with all the bells and whistles, all of the polish, and all of the things that come with a well designed, well deployed application.
Yes, you can take shortcuts. If you really wanted to, you could try to save money and put a functional prototype into the wild. It’s been done. But, as someone who has been on the production floor in this industry for 20 years, I would strongly advise against it.
When you hire someone to build an app, you want the greatest possible benefit from that app. You want the best of everything from scalability. You want that app to be usable, and robust, capable of withstanding a heavy load. And, you’re spending good money to do it.
The recent spectacular failure of the Obamacare website was a great recent example of a worst case scenario. They spent over $600,000,000 on building a powerful cloud application with a lot of features. But they launched it before the code was ready. My best guess is that they never built a fully functional prototype. Rather, they set out to build the final product before the system and the stakeholders were ready.
What’s sad about it, is that it never had to be that way. A well planned, well orchestrated app can be a success at $600,000,000 or $4,000. The amount of money that you spend on these things is not what’s important. Cost only covers the scope and the feature set of the application. A solid development process covers user satisfaction. Satisfied users means happy customers, clients, and employees.
And that’s why building a prototype is cricital to the success of your cloud app.
In fact, it’s so important, that it should probably be among the first things you ask, when you’re considering having an app commissioned.
“Will there be a throw-away prototype?”
If the answer is no, or the person you’re talking to starts to dance around the question… keep looking until that answer is an emphatic yes.
About Carson Derrow
