The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Prototyping a design?


I'm working on an application and the design of a certain module is giving me a headache. Some background first: I'm the sole developer on an internal application in an environment with loose rules and no mandated design methodology. While I do work with other developers, their experience do not really apply to application development.

Now, the problem is that the design of this module seemed OK at first, but is now severely under stress and must be heavily modified to support all the requirements, a process which is going to take a few days. This module is working correctly, the code is up to par and has been tested. But it just cannot implement all the requirements (which were not fully fleshed out when I started to work on it). Therefore a significant portion of this work will be thrown away.

This is not the first time this happen, so I'm starting to question my process. Currently, I'm working with a fairly ad hoc methodology:
 -- high-level design for the module,
 -- Test-Driven Design (on good days) for individual classes,
 -- repeat for each module,
 -- when needed, modify other modules to support the requirements of the new module.

When the requirements are crystal-clear, this process is OK. When the requirements are not so clear, it may lead into dead-ends. Changing requirements are a fact of life and cannot be planned. However, in my case, the requirements rarely change, but are always refined as issues are discovered while I code the module.

Starting tommorrow, I'm going to try another approach: prototyping the design itself. I'm talking about:
 -- some up-front design,
 -- passing around simple data structures (lists, maps, values...),
 -- no assert of any sorts,
 -- no error handling
 -- use only unchecked exceptions,
 -- GUI mockups with a graphical designer, 
 -- no tests.

I'm hoping that this prototyping approach will enable me to flesh out the high requirements and the high-level design prior to committing my time to writing production-quality code. Then I will simply beat the code into shape, replacing simply structures and algorithms by safer, better and tested ones.

There's a famous quote from Brooks that says "Plan to throw one away; you will anyway". The main point of this approach is that I'm planning to "throw away" (through heavy refactoring) a quick and dirty prototype instead of trying to come up with a production-quality design the first time.

My boss is a developer as well and I know that he's not going to try to make me ship the prototype, so no problem there.

Did any of you already tried such an approach?

D.K Send private email
Tuesday, January 10, 2006
Yes, I have done this before with great success. Rarely have I built an entire system as a throw-away but I have definitely build specific, complicated modules to "play around" with different designs. In my opinion, this approach works very well.
A. Nonymous
Wednesday, January 11, 2006
> Plan to throw one away; you will anyway

I don't. I plan to try stuff and make it better and turn it into a working program. Your second attempt at anything is equally worthy of being tossed, there's nothing special about the first.
son of parnas
Wednesday, January 11, 2006
As A.Nonymous and son of parnas demonstrate, it depends.

I personally do an odd mix of the two - I write paper diagrams, flow charts, abstract renditions of user interfaces, and so on until I've identified all of the potential ramifications (such as, "does this need to be a date object or can it just be a string?").  You do need experience to be able to do this well, but once you have the experience, it's far cheaper and faster to do it on paper or a white board than actually code a prototype.  (design-first development methodology.)

The fine details however, are worked out the way son of parnas describes - once I have things organized, I put them down into code and then increasingly refine the code until I get what I need. (iterative development methodology.)

I don't think there's a right way or a wrong way to do it, it just depends on your personality (your approach to coding) and the circumstances at the time.
Anonymous Coward
Wednesday, January 11, 2006
This is how I design and I think it is a great approach.

1. I sketch out the UI.
2. I make the exact UI I want in Photoshop.
3. Using the UI as a guideline, I write a manual describing how the system works.

That's the specification. Now, working from the specification, I create at least 3, but sometimes as many as 10 alternate implementations that will make the spec work. Some of these are coded all the way, others not. By the time I am done with this, I know which is best and go with that one.
Wednesday, January 11, 2006
If it helps, we have a tool, Lucid Spec, that is a free beta right now. It helps with GUI design and documentation. I would appreciate any feedback that anybody has.
Roger Jack Send private email
Wednesday, January 11, 2006
"Plan to throw one away. You will do that, anyway. Your only choice is whether to try to sell the throwaway to customers." (Frederick Brooks)

"If you plan to throw one away, you will throw away two." (Craig Zerouni)
First name thrown away
Thursday, January 12, 2006
> A creative man is motivated by the desire to achieve, not by the desire to beat others. (Ayn Rand)

Aren't people at their most creative in figuring out how to beat others?

This is from the above link by the way.
son of parnas
Thursday, January 12, 2006
If I'm trying to prototype non-UI functionality like algorithms that need different input cases, I'll create a quick, ugly app first. I'll add buttons for each algorithm version and have text boxes for reporting results, etc.

I find that quicker than creating lots of hard-coded test cases when I'm trying out ideas. The app code is throwaway but the best algorithms/business logic code are developed further.

On the UI-side, I'm a big fan of starting with mockups to get a feel for an application and get feedback from users (or anyone else that's available) before diving in to the real app. They often help to flesh out requirements and find different use cases and failure/what if scenarios, etc.

If you want an alternative to Photoshop for creating GUI designs and mockups, I've been using a really good tool for a while called GUI Design Studio that's worth checking out.

The cool thing about it is the way it lets you graphically connect different screens together and run them as a semi-working prototype. It handles complex screens well with multiple tabbed panels and things like that.

I've found though that the amount of prototyping I do depends on the nature of the project and I'm not sure there is a single process that works in all cases.
Gary Williams Send private email
Tuesday, January 24, 2006

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz