Make software dumber
Permalinks to this entry: individual page or in monthly context. For more material from my journal, visit my home page or the archive.
Ryan, an architect, talks about architectural software, but he could be discussing programs of almost any kind:
I don't want my objects to be very smart. That substitutes the tedium of doing the same thing over and over again for the tedium of debugging the relationships between smart objects that are being manic and overly helpful.
Think of Microsoft Word's eight-year-old list-numbering bugs, which are the bane of technical writers everywhere. Or "auto-fill" features that try to drop a company name into a Web form when you're trying to enter a user name that begins with the same letter. Or the series of dialog boxes, with contradictory and confusing buttons, that you sometimes run into when trying to delete something: "Are you sure? Yes/Cancel" "Save backup copy? Yes/No" "Software may become non-functional. Is this what you want? Continue Anyway/Revert/Cancel."
Ryan's examples are helpful clarifications:
I noticed something that evades the software industry but is obvious in practice: not all labour-saving features are desirable. [...] To wit: changing the floor-to-floor height in a building halfway through building documentation should be a big problem.
[...] What I enjoy about design is being able to use common materials in uncommon ways. Maybe I want to use a garage door for a dining table. The software says that garage door objects must be in a wall. So this whole smart object concept simply gives up the heart of architecture.
So software often tries to do unusual things we don't want to do, or makes doing inadvisable things easy, and prevents us from doing interesting things that it doesn't understand.
Any wonder that using computers is so often frustrating?