Demoing - is polish or functionality more important?

As has been mentioned on this blog before, the date for our demo of the OpenJet project draws near. I think all of us involved can feel a bit of the heat already. This first demo is supposed to be more of a prototype demo, so that means we won't have all the polish and not even all features finalized to this date. Personally I think we have made quite a bit of progress, and just last week, the pieces started to fit togheter and work with each other in a presentable way.

Now, the problem that I feel easily arise in these situations is how to decide what makes it into the demo. I think this is a common problem for everyone when it comes to developing software. It is easy to over-promise or just be overly confident and expect to have more functionality than can be fit into a single release. The problem with that is that cramming a lot of functionality into one release can easily mean that the features just doesn't work good enough. I for one am an advocate of "less is more" in the cases where it is possible.

Of course, a prototype demo isn't exactly the same as an actual software release - in our case it is implied that not all functionality and polish will be there. It is more of a way to show that progress has been made, and that the project hopefully makes use of technologies and ideas that will make it successful.

So this kind of transforms from a "what features should be included" to a "where do we draw the line" kind of problem. What is more important - more features in the release or a more visually appealing presentation? As a developer my first thought is that obviously functionality is more important, as that is what drives the website in the long run. But when I start to think about it, I am not so sure anymore. When we will present this project, as with many other projects, it won't be presented only to strictly technical people but also to non-technical people that are more of a representation for the end-users.

These non-technical people, or end-users, what will they remember from the presentation and how will they relate to it? I have a tendency to think that they remember what they see, and that they will relate everything said to that. I think it is easier to describe how functionality fits into the design, rather than describe how the design affects the functionality. I also think that the greatest technical solution or feature just won't seem that great if it isn't presented in a nice way, so the danger of demoing "raw" interfaces and only functionality is that people just won't see how good it is.

How do I think this problem should be solved then? Well, as with many other things, the golden truth probably lies somewhere inbetween functions and design. I think that if we can present usable functionality with a design that at least makes it look like a flight search website, we can have both technical and non-technical people relate to it. With usable functionality I mean features that can be used, but that might not withstand the abuse that end-users will put them through in a production environment. It is ok for an input field to not handle wrong input correctly in a prototype phase, as long as it handles correct input in a way that makes the feature work.

I think that the design at least should be done to the level where elements are laid out in a way it makes sense, the basic color schema is there and certain image assets are there as well.

We had this discussion internally in the team, and the above is how we have decided to do it. In the end, the application will be demoed by us so we can show functionality that might have not worked properly if used by someone not involved in the project. That way, we can make sure our point gets through, and if people like it, we can make it "fool-proof" for a future production release.