Lindsay's Lesson
A long time ago, in the dark days before “Agile” software or business development processes were thought up, I had the good fortune to work on a software project where Real Users were made an integral part of the development team. (I can’t go into details, otherwise I’d have to come over there and shoot you. The Official Secrets Act has a long memory and even longer arms!)
And what I mean by “integral part of the dev team” is this:
Lindsay (not her real name!) worked for the customer of the system-in-development. That is to say, she was one of the people who would actually use the system in its day-to-day deployment, and she’d be responsible for other people who actually put hands to keyboard-and-pointing-device in using the system. Key takeaway: Lindsay was not of the Managerial Class. She had years of experience running the system our development would replace, she was intimately experienced with the procedures and standards that systems operators would be expected to comply with, she knew all there was to know about how the user-base thought and behaved, the symbologies, notations and language they understood and expected to use. And her bosses made her sit in our office (many kilometres distant from her own) for a good deal of the time it took to develop the new system.
She was not some mid-level manager who thought they knew how the software would get used. She was the Real Deal who actually did use the old system on a day-in-day-out basis, who would, in the fullness of time, be responsible for transitioning staff and operators to the new system, and who would be at the pointy end of making sure the new system was fit for its operational purpose.
And she sat in our office. Watching us code and build and debug and curse. Smoking our cigarettes. Drinking our coffee (which was several orders of magnitude better than the cheap-and-nasty acorn-based stuff they served in her own offices) and bending our ears with all manner of irrelevant chatter. Damn, that woman could bend your ear!
You could say that a lot of her time was wasted. But…
I’ll never forget the day when I finally unpicked a particularly knotty UI problem that had been eluding me for ages. Lindsay looked over my shoulder and said, “Oh, but that’s the wrong way around, it has to go like this…” and showed me my mistake.
The work of but a minute to fix, and we moved on.
Over and over again, I saw similar things happen. Lindsay would wander about at random among the developers, peering over their shoulders, bumming another cigarette, and then she’d say something like, “What’s that over there?“ or “Why is that thing green?“ or “Is that really going to be on the screen?“ (No, it’s there to help me debug, but… message heard and understood: You don’t want to see that!) or “Can we make that a bit bigger? It’s really important and people will want to have it in sight all the time. Perhaps in the middle of the display?“
I cannot count the number of seemingly small things she picked out, almost all of which could be altered in mere minutes or seconds — faster than even Lindsay could inhale a mug of coffee — that made the system better. That made it behave in ways that the eventual users would expect and find familiar, comfortable. I can think of no higher praise for a piece of software than “comfortable“. I’ve not had enough comfortable software in my life.
The value she added to our development process — and to the end product we ended-up delivering — was incalculable. And remember that Lindsay was a fairly low-level functionary. Read: “not expensive to assign full-time to this role“.
A decade later, “Agile Process” advocates would recommend having a User Representative on the team. All too often that has ended up being some mid-level executive who (a) doesn’t really understand how the software will get used despite their own conviction to the contrary (see also: Dunning-Kruger bias) and (b) said executive will not be present during all working hours.
Compare and contrast the level of attention given by someone like Lindsay to the once-a-fortnight managerial progress review (aka Sprint Review).
Yes, this is a stark and discomfitting example of where and how remote only development cannot adequately substitute for bodies on-site. I believe that tools can be built to compensate, but I know of none that exist today. This is a significant gap, a deficiency in our New Stack toolset, and one that will have far wider impacts than just software development.