Monday, June 20, 2005

microISV's, Don't forget to prototype!

Dimitris Giannitsaros (that's an awesome greek name if I've ever read one. Too bad I can't pronounce it! :) ), is trying to do what a lot of us are trying to do. Start his own microISV. His first product will be a CRM system. He recently posted about how he gotten some coding done. I left a comment that pointed him to a recent post of mine titled, "Taking a Step Back, Defining Users, Uses, and Building a Wireframe". (Which is me admitting that I got started with coding too soon and now I'm stopping until my spec is in order.)

Mr. Giannisaros says he is leaning more towards what 37 signals wrote about in their, "Getting Real, Step 1: No Functional Spec", article than what I'm advocating in my blog post, mentioned above. One line from his reply said something very revealing.

"I need to see things on screen, test them and often go back to the drawing board."

I agree with this statement 100%. But let us investigate the process of doing just that and think about the fastest way to get to a finished product.

Keep in mind the end goal is a finished product. For your own sanity, you'll want to work as efficiently as possible. You and I are trying to start a microISV. I'm sure the last thing you want to do is write code for 4 weeks (nights and weekends for us wanna-be microISV's, no less), only to throw it out the window when it's done and "go back to the drawing board". I've been there.

I remember back to one of the first web applications I built for my current employer. It was a seemingly simple photo album web site. I'll spare you the details of the requirements, but this is how our development process went.

We got an understanding of what the site was supposed to do, and wrote it down. Ok, so it's storing pictures, displaying pictures, and it had a few other features (again, I'll spare you the details). That's flipp'n easy, right? WRONG! The first version of the site was completed in 3 months. We then spent the next 5 months going around in circles because each time we'd show the business client what we had built they would say, "Ok, but what about this." We'd scurry off and build what they requested. Come back and say, "Here! We've built what we asked for." They would say, "Ok, but can we do this instead? We want it to operate like this...."

Every time we showed them our working web application (which was built to the SPEC!!!) they would realize it didn't have some feature or operate in some fashion that THEY JUST HAD TO HAVE TO LAUNCH.

It damn near drove me insane. Here is what I learned.

A human being can not tell if an application does what they want it to until they see it. No one can read a text document or have a conversation with someone and once finished say, "That's it! That's the app I want!"

I'm trying to build my own microISV and I'll tell you right now. I thought I knew what I wanted. But it wasn't until I saw the result of my code did I realize how little I knew about what I NEEDED to build. Project Management software, right? I'm a Project Manager. I know what to build. WRONG!

So how do you combat the I-need-to-see-it problem?

It sure as heck isn't ignoring the functional spec aspect of system development. It's making a prototype.

I define prototyping as creating mock-ups of every screen and screen state of the application you are building. (You can cheat like I do, and not make the form-error screens. So sue me! ;) )

You heard me right, every screen gets a mock-up. But here's the kicker. How do you know you've created them all?

I'll let you take 1 guess from the following:
  • When it's dawn and your eyes are bloodshot from working for 24 hours straight.
  • When you get bored of this "prototyping" thing.
  • Whey you're just itching to write some REAL programming code.
  • When someone yells at you, "You need to get started."
  • You've identified all the potential Users of your system and have verified that they can now accomplish something useful with your application.
I once gathered the requirements for a charity-related web application (not a "web site", an actual "web application"). Each time we met I would go through the prototype with the client, trying to see if he could actually accomplish something useful with it. It took 3 or 4 iterations of the prototype before we finally had the screens in place for a system that would aid him in his work. In one of the later iterations we literally "discovered" a needed entity in the system. If we had missed that entity most of the original design of the system would have been scrapped. It was that drastic. In conversation the client thought we were taking it into account. But walking through the mock-ups of every single screen the User realized that he couldn't of done his job.

The first iteration of the prototype took a couple of weeks. Each iteration after that took a few of days to complete.

Contrast this with the photo-album web site, which is LESS sophisticated. Every time the Client saw the site, they wanted to move it in a drastic new direction. Each iteration of the system took weeks or months to complete.

Prototypes are quick, dirty, non-functioning, mock-ups of the system. They are as if you went into the future and took a bunch of screen shots of the finished product. Returned to the present and then wrote the system. How sweet would that be!

I can't stress enough the need for defining your users and creating a full and complete prototype. In my last blog post I mentioned wireframes as a stepping stone to prototyping. You are not required by law to make a wireframe. While you develop the app for your microISV no one is going to show up at your door and demand to see a diagram with a bunch of boxes and lines on it. But wireframing really helps you move from the user-definition point to the prototype point. (More details on wireframing from me. The first article I ever saw on the topic.)

Just in case anyone is curious, that photo album project didn't turn out with the world's greatest code base. Mid-project direction changes really hurt the quality of the code base. I'm actually working on re-doing the site from the ground up - 3 years later. And guess what I (along with the "new guy" I'm training) have spent the last 2 weeks doing. (Not every day, but a total of about 16 man-hours.)

We're writing out EXACTLY who the users of the system are and writing out EXACTLY what the users are going to be doing. We're currently working through a wireframe for each user type.

MicroISV's, don't fool your self into thinking that the whole app is "in your head". Force yourself to really spec everything out. I'm doing it for my Project Management application, and I already feel relieved. I won't be making functional decisions while I'm trying to write code!

You can make drastic changes to your prototype in a matter of hours. Changing code can take significantly longer. Your time is valuable. Do yourself a favor, work efficiently.

(Update 6/21: There is one more step before you're ready to do the technical work. Actually assembling the "spec". I'll write about it as soon as I've got the time!)

6 Comments:

Anonymous Dimitris Giannitsaros said...

Nice write-up! But I still disagree ;-)

"Prototypes are quick, dirty, non-functioning, mock-ups of the system."

And that's my problem with them. I do agree you have to think and analyze before coding. A prototype, a complete functional spec, a wireframe, stories are all ways to do just that. But for me, in order to feel something it must be fully working: having an above average style, saving records, etc

I'll let you know if in some months I throw out tons of code and be converted to your line of thought :)

Tuesday, June 21, 2005 4:30:00 AM  
Blogger Michael Sica said...

Damn! I still couldn't convince you!

By non-functioning I am referring to the application not "saving records". But you can still give it an above average style! At my current employer our graphic artist makes the prototype damn-near indistinguishable from the final application. He fakes stuff.

For example, if you're building a CRM system then have the ticket-creation screen's submit button bring you to a page that looks like a ticket has been created. You'll still get the feel of how the application would work. But you haven't invested a ton of time building a database, design the code, writing the code, testing the code, and bug fixing the code.

Good luck all the same... :)

Tuesday, June 21, 2005 8:32:00 AM  
Anonymous John Topley said...

I find PowerPoint to be quite good for this. You can come up with some surprisingly realistic looking screens.

Tuesday, June 21, 2005 12:36:00 PM  
Blogger Cubicle Coder said...

Do prototypes really save time? Michael makes a pretty good case that having no prototype can lead to lots of rework if it takes a long time to code up your application. I'm sure someone will argue Agile Method/Technology X prevents that. I don't buy that though. Fundamental requirement changes tend to blow your design up. Incremental changes can be done, but not a rethinking of the whole app.

I think Dimitrius is saying that that prototypes don't help enough - you've got to actually interact with a program to really get any see if what you're doing is going to work. If he's right, then prototype screens don't save time. You build them, think you know what your doing and are rudely surprised when you code.

One answer to this is faking the logic and making something that looks like it works, as Michael points out above. Another answer is that you can look at the prototype screens, imagine you click the button and then look at the next screen shot. Roleplaying the computer if you will. Lot less code that way, but perhaps easy to fool yourself.

Even if you agree prototyping is a good idea, you still want to do it in the fastest way possible. John suggests above trying powerpoint. Another idea this debate inspired me to blog about is paper prototyping.

Finally, this is a cool debate. It's great to see other microISVs discuss things like this. This helps me think about how I'm going to tackle things.

Wednesday, June 22, 2005 12:08:00 AM  
Anonymous Maxim Porges said...

I can only say one thing, and say it with the greatest sincerity: skip prototyping at your own peril.

After over two years of creating systems that have sailed effortlessly through design, development, and user acceptance, I can't speak highly enough of how prototyping has changed our development cycle for the better. I like it so much, I'm speaking about it at an industry conference next month.

- max

Friday, June 24, 2005 9:27:00 PM  
Blogger Michael Sica said...

Hey Cubicle Coder,

I love the idea of paper prototyping. I've done a bunch of it while I make the wireframe for Unity.

It's so much easier to write code when you know EXACTLY what you're building. User definitions, wireframes, and prototypes are all tools to get you to that point.

Friday, June 24, 2005 9:32:00 PM  

Post a Comment

<< Home