Jun 08
A study in software creation : Start thinking about the solution
Now we have a more detailed specification of the problem, it’s time to start thinking about how we’re going to solve it. A problem is only really solved if the customer thinks that it is – a solution that is perfectly valid to you might be totally unintelligible to them.
In the past, I had a tendency to solve the problem from my perspective. To take an example, when developing a web CMS, who wouldn’t view a website hierarchy as a list of “entities”, with “container entities” and “file entities”! Files and folders are so archaic, right? These new metadata tagged virtual representations are much easier to work with!
Well, to me, yes. But to the person who just wants to make their website attractive to Mom and Pop purchasers, no. They deal in a totally different set of concepts, and as they’re the users we must take both our technological expertise, and marry it with their end user expertise. In other words, write software they can use, and get the most out of (rather than spend their whole life in just 10% of your work because the other 90% is too confusing).
Step 2 : Think about it not just as a programmer, but as a user
This is probably why the current “free software” is fantastic for those of us in the hacker fraternity. We have the same mindset as the people that wrote it, and will clearly see that a “shortcut” is actually a symbolic link added by the file system, and not a pretty icon with an arrow on it. But 99% of end users don’t care – they just want to have Word run whether they click on the “desktop” Word, the “Start Menu” Word, or even a Word document.
As we’re going to design both an end user application and a programming, we get to see two user types in this project, hence satisfying both our geek side and our pragmatic side. This is a trick I’ve come to use on boring projects. If the software you’re writing is the most tedious piece of work you’ve ever seen, view it as a challenge in programming terms. Yet another online form processor? No! A chance to construct an elegant method of validating form input!
Of course, this can lead you down the route of ego massaging. A beautiful technical design, but either no solution or a solution that took 10 times as long as just writing the damn thing. I’ll discuss this next time, when we look at the specifics of the API design.
June 8th, 2005 at 8:39 pm
I’ve thought about how to handle the dreaded details that plague hackers. Those user interfaces, setup programs, documentation, etc.. On one hand, you aren’t going to learn as much by doing these parts of a program. On the other hand, they are necessary for any program you are going to give to an end user or even reuse yourself. They really are.
At first I thought, “why can’t everyone just get used to compiling from source and console apps? They just need to learn more.” I would fully follow that attitude when I wrote programs mostly for my own benefit. There would be little to no documentation and the API would get progressively more comlicated. What eventually happens is the API gets so complicated and the program gets so brittle that I have to abandon the whole thing or rewrite it. By simplifying programs, you can divert your intellegence to new problems and programs. Let the workshop get dirty while you’re working on a project, but clean it up before you start the next.
Perhaps a diagram would help:
Linux expert’s tolerance of complication:
———————+
Average user’s tolerance:
——–+
Bad programming practices effect on complication:
—-> —–> —-> —-> —-> —->
So although average users require more frills on their program, without paying attention to this requirement, complication goes past the point where even you can understand it.
June 8th, 2005 at 8:50 pm
A good point, a very good point. I’ll write about my experiences with my new API design strategies in a few days, and the mapping between end user functionality (and hence “user tolerence”) and actual code and design complexity is an interesting area to think about.