Deviant Users

Deviant Users

This article caught my eye as it relates to computer systems users and how we programmers approach them. We analyze what they need, give it to them and walk away. To us the value is self-evident because logical and wonder why they don’t use the software or use it incorrectly or want a rewrite.

I’ve been wondering if the installation phase of our project plans is incomplete. We focus entirely on the technical issues involved: loading programs, modifying the database, running conversions and bridges. But we need to convert and bridge the user community too. Yucky human stuff. Maybe we, too, can use deviant users.

 

More Government Bureaucracy

Could we use a federal cabinet level Department of Information?

First caveat that comes immediately to mind: any such department must not become an Orwellian department of secrets and disinformation. And not allowed to over step its bounds. Why does the Department of Home Security worry about copying DVDs anyway? Its mission should not be gathering information or hiding, sorry securing information, we have enough agencies doing that already, but whose goal is passing out information. 

The second caveat is prohibit it from being another regulatory nightmare: information technology and capabilities are evolving far too rapidly for diktats of a government bureaucracy. 

We need to keep the government of, by and for the people and not special interests, lawyers and bureaucrats. Wait, my feet feel soapy. 

The goals of a DOI?  A department whose mission is the promotion of transparency, open access, digital rights, accountability and other such garden of eden buzzwords. Information is the foundation and structure of modern life. Maybe we need a high level, high visibility entity to provide care, feeding and awareness modern Information requires. 

It could run a clearinghouse to share tips, experience and expertise amongst for government departments and agencies. Sometimes I wonder if they talk to each other. Maybe they just need a forum. 

It could publish advice and recommendations to the information industry—but not laws or regulations. Perhaps include my pet peeve: why not research software development methodologies—see what techniques actually work? Programmers, analysts and managers need readily accessible and unbiased information about our own work. Every project methodology I’ve seen stinks of marketing promotion based on anecdote and not enough hard unbiased research. Academic research papers are written in, well, academic jargon and not usually accessible by most programmers. Not that I make an effort to read them either. 

But first, eat our own dog food. Because government projects seem to fail so often and so publicly, government needs to research software methodologies, languages and tools to get the most bang for our bucks. The first Big Truths shouldn’t take too long: Big monolithic projects are Not Best Practice (Bad Practice?). Or is that just another unscientific conventional wisdom?

End user programming

An interesting comment in http://www.technologyreview.com/featuredstory/515926/how-technology-is-destroying-jobs/ about how industrial robots are getting cheap enough for small manufacturers. I suppose it’s only a matter of time before they are cheap enough for small enterprises—both because industrial robots penetrate down market and because domestic/hacker robots percolate up market. Backroom stocking and inventory? JIT one-off manufacturing much as we now have JIT photo processing completely automated at drug stores? Think if we have not just custom tailored suits but shirts, pants, shoes. 

How to apply this to IT system development? How do we automate software development? Computer systems depend on large scale subsystems like DBMS and network protocols and smaller language dependent libraries. We have had programming guidelines, like Apple’s UI guidelines for decades now. You can wire up decent applications using user oriented development tools embedded in applications like Excel and Access. 

If programming were a language, knowing what library members exist is like having a vocabulary, differentiating similar functions is like having a thesaurus, having a need for a function and finding a library member that handles it is like a word finder, or reverse dictionary. Readers do not need a lot writing tools, books, about English: a simple dictionary suffices. Writers need lots of reference books: thesauruses, grammar and usage books, synonym books, and word finders. Word finders are the most problematic. How do you find that word or phrase ‘on the tip of your tongue’? How would you find the word that describes a window set high on a factory wall or ceiling to let in light? [Daylighting, or clerestory]. Word finder books, reverse dictionaries, are a start. 

And here, I think, is the nub of programming: learning a programming language, while non-trivial, isn’t that hard. (Yeah, I know, the practice of programming is something else again.) Learning all the libraries and their members needed to wire together a system is time consuming and a study unto itself. A user who just wants to create one system for himself doesn’t have the time or the inclination to study libraries anymore than a reader wants to learn the words for every concept that comes along. So a library finder like a reverse dictionary would go a long way to democratizing programming. I know i’ve gotten used to fishing for synonyms using google search. 

Now, end-user programming still has a lot of problems. Like that Excel range checking bug (Reinhart-Rogoff. See for example http://baselinescenario.com/2013/04/18/more-bad-excel/). End users would need automation tools for testing and all those other best practices that envelop a production system, as opposed to a program.

Or perhaps what users will need in the near future are not full on programmers but coaches and consultants. Then, too, they’ll see how hard it is translate requirements into a design and specifications. Or worrisome thought, maybe they’ll do a better job of it.

How Programs Learn

I’ve read Stewart Brand’s How Buildings Learn and found I was jotting down notes every page for ideas to apply to systems analysis and computer programming. I’ve always been intrigued with the analogy of architecture to programming: large scale works difficult to change during construction, difficult to maintain, and perhaps equally difficult to to state requirements.

Some take away topics: High Road v Low Road: at the extremes cathedrals versus reusing warehouses as workspaces and habitats. Architecture as ART without concern for use. As Built documentation. Integrated teams and bottom up feedback loops (TQM, Agile?). How there are different parts to a building with their own requirements, maintenance, and replacement life spans (DBMS, architecture, applications, UI?).

Like every book I read, the lessons get mangled in my head over time to what I want to have read, so I’ll need to reread it soon. I recommend you read it.

User Manuals in Fifteen Minutes

What if we designed the Training (or user?) manual to be read in stages?
Personally, my eyes glaze over after about 15 minutes. Am I the only one? I doubt it. Otherwise would we have the acronym RTFM?
What is we designed the manual with this limitation in mind?

First: The absolute minimum to get started. —Though with if we designed the system with this mind—design the system to make the core system—as used—readily understood? Plus we can skip the usual explanations of what people already know, get to the meat.

Second: Teach additional features in short, 15 minute articles. Eg In Scrivener: how to use Project Notes. How to use File references (links, especially external links).*  It might even be easier to write these with the imposed 15 minute limit. Instead of with the mindset, ‘oh God, this is War and Peace’. The writing would tend to be less “this feature does this” and more “to do this use these features”.
Users and techs could collaborate more.

If the manual is written early in the project, say as part of the design phasse, features might be discovered as requirements faster. As in the “why can’t we do this?” variety. [Also might help to avoid the MS problem that they already have the feature, people just can’t find it.

* Notice I’m assuming you’re familiar with Scrivener. Which is not a good assumption, I know, but for homogenous users, it may be valid to refer to shared experiences. As in this department, we all used the old system so you can compare this system with that. (And yes I realize at some point people will not be familiar with the old system.)

The layers of a building and the layers of an application system

 

I’m reading Stewart Brand’s “How Buildings Learn”. In it he explains how buildings consist of six layers: setting, structure, skin, services, space planning and stuff. Setting is the physical site itself including the foundation. Structure is the fundamental building. Skin is the exterior. Services are HVAC, electricals, plumbing, wiring. Space

planning is the layout of the interior. Stuff is the stuff we into the space. Explicitly stated like this, we can see that buildings evolve differently and a different rates depending on the layer. Stuff changes constantly and quickly. The setting barely changes at all.

Programmers attempt to account for different layers through the Model-View-Controller design. Roughly speaking, the model is the structure of the data. Controller are the functions that process the data. And View is the user presentation. The data model is the hardest change and the user presentation the easiest. 

For users, during development, you need to concentrate on getting your data requirements as solid as possible. The user interface (UI) is relatively easy to tinker with. If you’re running out of time, concentrate analysis on the data. This is a gross simplification of course: the user interface is how you understand the data, in much the same way you understand a person through the stories you’ve heard about him.

For me as a programmer, trying to design a system for flexibility has never worked. The systems always seemed to evolve in the direction opposite from where I thought it would. But thinking of change in terms of these layers holds, I think, promise. The MVC design pattern might be enhanced a bit by thinking of it not just as a way to separate out chunks of the problem space but as a means to manage change. 

For users, once you get the system and have had a chance use the system, you’ll think of ways to improve it. But think of it like a house: Changing what data and the structure of the data is like changing the foundations of your house: a major project. Changing the layout of a screen or the flow of one screen to the next is relatively easy and like remodeling the bathroom—if just as expensive.

Let’s Talk

Most of the computer systems development projects I’ve worked on we programmers barely even talked to the users. [I’m writing about corporate application development, not internet applications.] There can be good reasons for that. Some programmers you want to keep well away from normal people. Some programmers want nothing to do with normal people. Many have poor social skills. OK, that’s just a stereotype. A stereotype so prevalent it’s a common cliche of TV shows. 

But I wonder if socialization isn’t a skill programmers need to learn just as much as learning the latest programming language. We programmers think our job is to write code. But code is always in the service of business needs. Applications are a tool not an end in itself.

Atul Gawande in his book Checklist Manifesto wrote one of the uses of checklists is get everyone involved to introduce themselves so they can work as a team. Now some programmers will argue that that applies to the technical types introducing themselves to each other—designers, architects, programmers, DBAs, those sorts of people. Not the patient or the user. But users are an integral part of the project. They provide the requirements and requirements have traditionally been blamed for project failure. Maybe we need to learn who they are and how to listen to them and thereby what they want.

We programmers tend to meet only a few of the users, we like to think they’re representative but my experience suggests they often aren’t. We tend to meet the more senior users and listen to the more articulate users. 

My question to you is how many of you programmers make an effort to meet your users and have you found the effort productive?