Why I Don’t Worry About Being Wrong
I was reflecting on some of the technologies I’ve worked with over the years, and how relevant they are to the work I do today. In particular, I was thinking about my time at Abbey National, using a programming method known as JSP. No, that’s nothing to do with Java, you youngsters; it stands for Jackson Structured Programming. Invented by Michael Jackson (no, not that one!) it was the first real method I ever encountered. Well, other than the fag-packet-spec and the let’s-try-this-and-see-if-it-works-this-time methods so sadly familiar to programmers everywhere.
Using very simple diagrams JSP describes the flow of control through a program or even a whole system, makes flag-setting for control redundant, and enables you to quickly and easily devise test-plans to do all-path testing. Iteration and branching are made explicit within the diagram, single-read-ahead is implicit, application-level exceptions are not so much handled as avoided (other than in what are known as “bottom-ups”: hand-crafted code which is plugged in to do something the method couldn’t handle perfectly, and which I always felt were a bit of a cheat but were admittedly a useful workaround sometimes). It lets you devise processes which run for years, stopping and starting, and picking up where they left off even after the machine has been switched off for a week. In slightly more specific terms, JSP lets you describe a long-running finite state machine but instead of leaving you to work out the coding yourself, it actually helps you. More up to date programmers might be familiar with SSADM, which is similar, although not quite the same thing.
To write a new program which takes an input stream and produces an output stream, you model the input and output as sequences expressed as JSP diagrams. You then overlay the two, find the places where the two diagrams overlap, and merge them together. All that remains then is to fill in the operations which actually do the task.
It was a brilliant method. I was there when the six-year rewrite of Abbey National’s Secured Lending System went into production, all done in Jackson – actually JSP COBOL – and it worked first time. Most projects of that scale never see the light of day. I don’t take credit for that success: this was a department of perhaps 150 very bright people; I was just one cog in that machine.
After I’d been working with JSP (and the higher-level analysis method JSD) for about 4 years, an internal vacancy came up for a programmer in another department, working on an exciting new project. I had moved from a development role to a support/maintenance role, couldn’t see much of a career path (the department by this time was top-heavy) and consequently I’d been contemplating a move for some time, so I applied for the position, and got it.
Once I got there it became clear that the project wasn’t new. It had been going for roughly two years, and hadn’t even got out of the initial requirements stage. Someone in the upper adminisphere had seen the success of Jackson in the Secured Lending project, and decided that to get the project moving what was needed was some Jackson. Since I was the longest-serving programmer who knew Jackson who had applied, I got the job.
The first task was training. None of my new colleagues knew Jackson, so we were hooked up with a consultant/mentor, a great guy who really knew his stuff. I admit was in awe of this guy, still am. He was a guru. A real guru, mind you; not one of the ubiquitous, plastic gurus you encounter on the internet every day, but a real, one-in-500,000 dude who really knew his stuff. One day he would be tutoring some department or other in whichever method they were using at the time, and then would swan off to an international meta-modelling convention, where he and other gurus discussed not just methods or models, but models of methods, and methods of modelling methods, and models of methods that model methods, and so on, to levels of abstraction that made my earwax melt just thinking about it.
Now, anyone who knows me probably has noticed three things. First: I’m a do-er. I’m not a sitter-about-er. Second, I’m passionate about what I do. And third, I’m not backward in coming forward. I say what I think, and although I try to think before I say it there are times, especially when I’m stuck in a meeting and want to move things on, I forget and speak my mind perhaps a bit too directly. Not nastily, I hope, but … well.
In one session we were discussing the richness of the information in a Jackson diagram. And believe me, those diagrams really are very rich. Although they are just boxes and lines, they describe processes so fully, and reveal subtleties that you’d miss otherwise. Even today I sometimes knock up a quick JSP diagram when I’m working on a class that I’m stuck with. I don’t try to translate the JSP into code, but the diagram helps me see the bit I was missing. But I digress. We were supposed to be discussing the rich information in the diagram, but we got bogged down in something really trivial. Foreign keys.
I try to be patient, I really do. But on this day, it seemed to me, that my colleagues were being wilfully obtuse. Why couldn’t they see that a foreign key is simply a pointer to some other “thing”. And yes, you techies, I know that’s a loose definition: let me ask you some time what an exception is. But the point is that in the context of the session, that’s all anyone needed to know. And so I said so. It was probably a mistake to wait patiently for 45 minutes into a one-hour session to do so, but I had been trying to be polite. I think I followed it up with “So, can we move on? Because time is a bit limited” (our mentor was only with us for a handful of hours a week, so our time with him was pretty precious).
Anyway, this caused a bit of a scene; the team leader left the room because she was “too angry to speak” and I received angry scowls from the other attendees, and things were a bit awkward for several days afterwards.
The one thing that sticks in my mind, and the thing I kept returning to today in my wool-gathering, was what our consultant/mentor said to me after the session. He took me aside, and said, “You will always be forgiven for being loud, obnoxious, and wrong. But you will never be forgiven for being loud, obnoxious and right.”
So I don’t worry too much about being wrong; I worry about being right.