Savvy Duck: Prototypes

Starting a completely new project is an adventure. I’m never happier than when I am figuring out how to create the framework for a new application. There are thousands of challenges to navigate and the right solution means proactively attacking them at the beginning of the project rather than reacting to them through the development cycle.

Prototyping is a quick way to check if each of the major components will work as well as establishing a working model of the user interface. Web applications are especially prone to late development cycle type challenges because of the number of components and the interaction of those components. You don’t know how difficult things can be until you are most of the way there, but a prototype lets you experience many of those behaviors early enough that you can change directions without major development delays.

What to prototype and how much is important to figure out. Each major component should be proven before you commit to a massive implementation. There is nothing worse than having a team working nose to the grind stone only to find out that the application cannot scale beyond a few hundred users without a prohibitive hardware investment. That means adding another hard development cycle to remove the bottleneck and fix the problem.

The major areas of any web application include the user interface, security, the database and its interface. All of these need to be prototyped very early in the development cycle as they have huge impact on the final product.

The user interface includes the basic design, any third-party javascript libraries and anything novel. Novel techniques or components often need to be tested with customers, friends or family very early because they may not be intuitive to anyone but the developer. Novel components can be brilliant, but they are new and so it may be wise to take the time to verify them with users. Third-party libraries need a couple of quick checks, like “does it work with my customer’s browser” , “can I do customizations quickly” and “does it work at all?” Finally, putting the basic design of the application in front of an audience is hugely helpful in that their comments may change the workflow or the look and feel.

The UI also includes server side components. They need to be tested, but often not as rigorously as what runs on the browser. These components tends to have been around for awhile and have documentation and a user base that can help you through most problems. You still should establish that you can perform ajax operations for reading and writing to the database and that security will work. Some server side frameworks don’t lend themselves to ajax style operations without a series of contrived operations. Sure, they may work after a lot of effort, but should you still use it after all the weird hoops? If someone told you can ride your lawnmower to work would you do it? Just because something can be done does not mean you should do it.

I like doing a prototype of a UI and get it to the customer as quickly as possible. It happens often that customers don’t like the pallet or the workflow. Nomenclature for labels in grid controls may not be the same terms a customer is used to either. The prototype’s UI can be easy to fix and the customer realizes that you take their suggestions serious.

Security is really important to test and get into the product from day one. Security gets embedded at every level of an application. Not only is it the gatekeeper to all the valuable information within your application, it is also an excellent bottleneck and performance killer. I’ve been involved in several projects where security was shoehorned in near the end. Fix it early and you will be able to swiftly move forward.

Got a database? No matter if you are using J2EE, .Net, Rails or PHP, do a sanity check and make sure your database layer will minimally work. Its another one of those great performance issues. Code needs to work reliably and the database needs tuning.

Prototyping each one of these areas is really handy. Sometimes the “thin thread” for a work flow is hugely valuable in establishing whether the customers like or and if it works. The more that works, the better. Most importantly, there is nothing to say that a prototype cannot be the base for the product or feature itself. It shouldn’t be treated as code to be thrown away or chalked up to a learning experience unless things go terribly wrong.

I’ve been very focused on proving the technology from customer, reliability and requirements viewpoints. A final argument is that you have a good idea for how long it takes for something to be done. Nothing like having a pretty good feel for the time line before you get into the thick of a development cycle with publicly known delivery dates.