Systems Approach v. User Approach

I wanted to follow up on Bruce Eckel’s thought about “thinking in zope” (or thinking in a particular idiom or computer language). Previously he argued that one cause of bad design is a developer’s failure to appreciate customer problems and what they really want. The problem, he argued, boils down to gathering and heeding user requirements.

Now he’s changing his tune a bit. He’s saying that a systems approach (understanding the computer language/tools first before you can tackle actual problems) might actually be preferable. Zope, I’m afraid, is a platform that forces you to think differently; you are dealing with objects, not tables of data; you are dealing with macros and slots and methods employed on objects. That is quite a contrast to the typical notion of separating data from logic (with RDMS), and it involves a lot of iteration; you are creating instances rather than filling tables. Instead of dealing with static php pages that trigger a lot of data calls, you are using paths to convey objects that are acted upon. Quite frankly, I’m not used to thinking this way although that doesn’t mean my plastic brain can’t change.

Andy McKay’s book starts out with a user-centered approach (i.e., explaining how to work the interface), but actually we need to use a systems-oriented approach just to get started. I can manipulate the interface, but can I actually create templates? I need more.

The problem comes when familiarity with systems imposes patterns on user workflow. The developer needs to adopt two nearly contradictory mindsets: that of user who just wants to get the job done, and that of system-aware coder who wants the workflow to fit within the language’s parameters. It’s not that the developer dislikes the user; it’s that he builds things in terms of what’s already been built; the principle of least effort seems to apply. On the other hand, a good developer can recognize when a new use case seems to justify for a new tool or algorithm.