Hugs not Bugs

Ok, this week my posting is a self-pitying rant, pure and simple. The topic: asking for help from software developers.

For some reason, our industry has adopted the following value: if you need help, too bad; if you found a bug, we will do all we can for you.

At least, this is how we seem to be perceived. I spend much of many of my days at work dealing with accusations of incompetence, which accusations are actually poorly-disguised pleas for help. Whenever a client or user needs my considerable analysis and analytic skills, they ask for help by accusing me of having bugs or poor design.

Yes, I have bugs and yes, I don't have a problem with bug reports. I am highly confident that I can fix any bug and I have few enough of them that I am happy to fix whatever needs fixing. I am not talking about bug reports: I am talking about something else. Here are two examples from the recent past; one is from yesterday, in fact.


Case 1: Just Fix It!

A client reports that a system of mine which is designed to create orders is failing to create orders. She knows this because my system comes complete with an built-in audit module that told her so. My system is at the start of a very long chain, going through another department in her organization and through two other vendors' systems.

• I confirm that my system generated a request to create an order, which request was acknowledged by the next system.
• The bug report is repeated, this time with a slightly ruder, slightly more accusatory tone.
• I confirm, by looking at logs that are not my own, that the request did not reach its final destination.
• I ask the intervening department to confirm that the request went through their system and out the other side.
• I confirm that the final destination has two interfaces through which the request must pass, and that I only looked at the second of those.

I am slated to continue tracking this down, through other vendor's software as configured by other people, not because this is in any meaningful sense "my" bug but because I am good at this and am being paid to do it. They need my services, I am happy to provide those services: why does the request for service have to be framed so negatively?


Case 2: Its Not Working!

In one of my professional identities, I provide technical support for a line of technical products which I designed. This gives me contact with the retail world and a sense of how my work is actually used in the real world. Most of what I learn is terrifying and makes my consulting clients seem like ever-pleasant geniuses.

I recently fielded a "bug report" that a four-year-old version of our software had mysteriously stopped working and that if there was a patch, the customer lacked it.

This is, of course, absurd on its face. I directed tech support toward a tech blog posting I had made some time ago about debugging configuration files, since this was obviously a case of misconfiguration.

The reply, as forwarded to me, was that the data had not changed, the configuration therefore was right and that the fault lay with the software.

This was ridiculous, but arguing with someone who is either this ignorant or this belligerent is a waste of time, so instead I used our excellent configuration debugging tools, which are available free for download to any of our customers, to find and fix the small issue with her configuration: Voila! it all works--or rather, it was working all along, but now her configuration matches her data.

Naturally, it turned out that this particular user was one of the few to send a thank you note, a nice thank you note, when she got the resolution. So I try to remember that not every difficult user is a troll: some of them just need help and they apparently don't know how to ask for it.

Stone Soup

This post is about business process automation: using computers to make people more efficient and effective. These days, with computer hardware so fast and software so powerful, the most precious resource in most business settings is human attention. Computer systems should help conserve and focus human attention, not drain it away.

Growing up, I read a lot of folk tales and as an information systems consultant am often reminded of one of my favorites: Stone Soup. Here is the uninspired Wikipedia synopsis, but find a copy of the real thing if you like the idea.

The basic idea is that while a group of people are unlikely to pull together to help you, even if it helps them, they will participate in a sure thing.

I find this is a common situation with our clients: no one wants to stick their neck out to launch a project, but everyone is happy to participate in an already-going-well project, especially if participation buys them something.

Thanks the last 20% rule (apparently more correctly known as the Pareto Principle), I find that I can do the 20% of work that sets the stage on my own dime, as a proof of concept, then do the rest of the work once the client sees that success is just over the line.

In fact, once they get rolling, clients often for 120%. Why not? The first 20% was free.

So, as as customer, why not get the 80% for cheap? In theory, you shouldn't settle for the easy 80% because, as any one with experience with business process automation  can tell you, that easy 80% is what separates the bad from the adequate; that final 20% is what takes you from adequate to excellent.

I am a realist, however: for many (the majority?) of organizations, going for the easy 80% would be a big step up. So by all means, try to get it. The tricky part is knowing how much you can get out of your current environment. If the environment you have is at capacity, then you have to look elsewhere for improvement. Either get some consulting help or new software or (gasp!) put manual processes in place to make up for computer system shortfall.

Sometimes we see computer systems which are fine systems but not properly configured for their environments; in this case, if people put manual procedures in place as work-arounds, we understand. Adding manual labor is always regrettable but sometimes necessary.

But remember the story of the man, the boy and the donkey: first the boy rides and passersby chide the boy for letting his elder walk; then the man rides and the passersby chide the man for letting his child walk; finally, the man and the boy carry the donkey and the passerby mock them for doing the donkey' work. If you are carrying your donkey, you need to consider the possibility that someone isn't doing their job.

In Praise of Pausing

There are two situations in which I appear to be doing nothing: when I am thinking and when I am in what I call the Safety Pause.

Thinking

The thinking case should be obvious: as a software designer and prototype builder, a good part of my job requires thought. Thinking, at least when I do it, look like particularly quiet goofing off, with a crucial difference: I am thinking.

I accept that believing that I am thinking and not day dreaming requires a leap of faith. In order to foster trust, I try to offer what proof I can, such as white papers, design notes,rapid coding that comes from a solid plan, etc. but I find that this is often not enough to convince some people. These people seems to feel that if my fingers are not on the keyboard then I am not working. God forbid that I have coffee with a user as a part of my requirements gathering.

Don't most white collar workers have to think? Don't people take notes, write outlines, ask questions and then consider the answers to those questions? Or is there a prejudice about computer people and goofing off? Lolly gagging, frittering away time in frivolity; are these vices peculiar to computer specialists? I think not.

It is true that, as a group, we blur the lines between work and play: we play at work and we work at home sometimes. We even work in the shower sometimes (see below). I will even grant you that until I started keeping track of my time very carefully, I tended to overestimate the amount of time that I worked at home and the amount of time that I goofed off at work.




However, it is not true that I was working less that 40 hours per week and it is not true that when I need to think, I appear to be just taking up space. Coming up to me to ask what I am doing, or to jokingly imply that I am wasting time is the exact opposite of helping.

(For me, the one exception to this etiquette is the forest of unshaven young guys staring moodily into their laptops at Starbucks. I am willing to assume that they are just wrestling with writer's block or dealing with having an empty head.)

The Safety Pause

The Safety Pause is my version of the carpenter's adage "measure twice, cut once." In my consulting practice, I find it best to consider, reconsider and then pull the trigger, be the task writing code, designing software or processing data.
 
The Safety Pause lets the rest of my brain chime in and prevents "God, I just want to be done" syndrome. I embraced the Safety Pause because I kept finding that after pulling the trigger on something, the very next instant, something would occur to me that I should have done differently, or even why I should not have pulled the trigger at all. I decided that having that revelation BEFORE I pulled the trigger would be better. So I started deliberately walking away and doing something else. The thing-into-head-popping is not as quick as when I have shot myself in the foot, but it often happens.



I also find that sleeping on a problem often means that I wake up with a solution all ready for inspection. Sometimes this solution is flawed, but it is often a good starting point. I even find that ideas come to me in the shower, which is a drag because I rarely remember to bill for showering or sleeping, and yet....



Conclusion



So the next time you see a co-worker staring off into the middle distance, just leave them alone. They may actually be thinking. And if you see a co-worker finish most of a task and go get a cup of something hot before doing the final work, remember that they may just be trying to avoid trouble down the road.

Just The Fax

I recently had to review the operation of a fax-based system I created to deliver clinical reports to doctors. Someone claimed that a report had gone astray and in response, I had to dig through the logs and the database rows to confirm that the report had been delivered.

This left us at a very faxly impasse: I say the report arrived and they say that it did not.

This somewhat tiresome trip down memory lane made me reconsider the place of fax technology in the current environment.

Once upon a time I liked facsimile technology. It was the best way to deliver nicely and reliably formatted reports to a specific location with a low chance of eavesdropping.

(Once the paper report came out of the fax machine security was an open issue but it was also someone else's problem.)

I still like the maturity of the technology and the fact that I have lots of mature code that does cool fax-related things.

What I do not like is the usual list of issues with a waning technology as well as some fax-specific issues.

The usual waning technology issue are these:

- The infrastructure (POTS) is shrinking; in fact, since our office went VOIP I cannot debug faxing in our office.

- The hardware is harder to come by; I am having to hoard fax modems to ensure that I have spares.

- The system software is no longer common; it is not installed on servers by default and it is not easy to integrate serial lines into the clustering environment.

The specifically fax issues fall into one of two categories: inherent and acquired. By "inherent" I mean that these issues are a part of the faxing technology itself. By "acquired" I mean that these issues have arisen because our environments and expectations have changed, making faxes seem degraded by comparison with prevailing norms.

The inherent issues are the unreliable delivery and the degradation of retransmission; a fax of a fax is often pretty hard to read. The unreliable delivery is more of a problem: paper jams, ink runs out, fax machines get turned off and phone lines are sometimes busy. I refer to the protocol jargon meaning of unreliable: it may wok most of the time, but I cannot really tell if it worked, at least without calling and asking.

The ways in which our expectations have left faxes behind are these:

- The transfer speed is now rather low.

- The data is not integrated into anything else: the report lands on paper and stays there.

- The report arrives at a fixed physical location but more and more we move around when we work.

- The security is now rather lacking; back in the day, the point-to-point nature of POTS was pretty secure. Now, the lack of passwords and access logging is pretty lame.

My investigation ended with my system claiming to have delivered the report and the user claiming that the fax never arrived. Finally someone in the target office found the paper and all was once again right with the world.

All's well that ends well, but I must confess that I am looking forward to the day that doctors find something to replace faxing. Soon I hope.

Lack of Feedback = Madness

A mental health professional I know once defined insanity as the state in which the model of the world inside one's head is sufficiently out of alignment with the world outside one's head. I found this to be rather uninspiring at the time, but the older I get, the better this definition seems.

I note that there are at least two ways to end up in the "insane" category: either through some organic problem, ie a malfunctioning body, or through bad input. It is this second category that interests me today because I see a parallel to a common workplace situation.

The common workplace situation is as follows:

1. A manager makes a strong statement, such as "everyone needs to be using System X by Some Date."
   
2. The rank-and-file try to convert to System X and find issues; they bring the issues to their manager who punishes them for their failure
   
3. Now that they know that "failure is not an option," the rank-and-file claim to be fully converted to System X by Some Date--perhaps even earlier.
   
4. In fact, System X is imperfect (as is every system) and there are myriad hidden workarounds in place.
   
5. Officially, the manager's decree is in full effect and all is well; actually, things are very different.
   
6. The manager's model of the situation diverges ever farther from reality; in  effect, the manager is going crazy.
   
7. At some point, there is a crisis; my favorite is the crisis of cutting off funding to consultant running workarounds or to maintainers of systems other than System X. This crisis has measurable, undeniable consequences.
   
8. The manager comes to the painful realization that all is not as he or she thought. He or she feels betrayed and blindsided. The members of his or her organization feel that his or her ignorance (read: insanity) is her or her own fault. Everybody loses

So what is the moral of the story? The moral I take from the story is this: if you let your boss go crazy, that is your fault. If your boss refuses input and goes crazy, that is his fault. In either case, you probably need a new job if you can find one.

How Much Technology Is Enough?

I am generally a minimalist, at least when I am designing or implementing information systems. To me, minimalism means doing it all, but not to excess.

So when I go out to dinner, I will have a steak, a baked potato, a spinach salad and some red wine but will have a small steak and a reasonable amount of wine.

I realize that many people would quibble with that definition of minimalism, so instead in this post I will use the term "optimal" to mean "everything you need but nothing that you don't need."

While I feel that the finished product should be optimal, I do not feel that a project's resources should be only just enough. Instead, I believe in what a colleague once referred to as "cheap insurance." By this I mean that I believe in providing an excess of whatever critical resources can be cheaply and easily procured.

For example, I often buy a USB external disk (which we call a "can") or two just for the project to make sure that disk space and back up will not be a problem. USB cans are cheaper than having a project delay or a project  disaster. Similarly, I keep a few unused computer system units around because you never know when you will need a special purpose machine or want go provide a contractor with a machine.

All this keeping of stuff makes me s bit of s techno pack rat; although the difference between techno pack rat and project savior is often timing or dumb luck. And shelving is cheaper than failure.

Since we often help customers get off of old platforms, I have another reason (or, according to some people, rationalization) for keeping dated technology around: the ridiculous pace at which the high tech world changes.

Even applied technology tends to be very much of its time: often the dated peripheral has to match the dated system unit and match the dated driver running under the dated operating system. All too often trying to use a shiny new peripheral on a mature system simply does not work; worse, sometimes it works to some extent, sucking up your time as you fiddling a vain attempt to get full functionality.

Another reason that I hoard old tech is that I have a deep respect for working systems. I know from painful experience that every time you fiddle with a working system you risk having a systdm that will never work again. Am I a nervous Nellie or a scarred veteran? Opinion vary, but I will stick to my cautious ways. I like taking chances just fine if I have a fall. Ack position.

Not only do I fear that working systems are only working until you fiddle with them: I also fear that projects of more than trivial scope never go as planned. I know that contingency planning is good but not enough, so I want more: I want options. I want flexibility. So I need lots of extra stuff in order to be able to suddenly decide that the system would work better if there were two servers instead of one, etc.

I find that debugging distributed information systems sometimes requires creating a parallel universe. If the bug or issue or misconfiguration or mismatch is deep enough, you need a testbed in which to try changing fundamental aspects of the system. Sometimes I need a consult from an external expert, in which I want to be able to deliver a working prototype to them while still having a working prototype in house.

So I find that in order to deliver enough product, I need way more support than I expect. However, I notice that the same people who tell me I am going overboard on the technology resources for projects are often also the people whose output is lacking that final polish, those extra features that distinguish adequate from good and good from great. Shelving is relative cheap: I am going to keep pushing for great.

(Although even I have my limits: I have 8 bit NICs and CGA video cards I would be willing to part with at a great price.)

In Praise of "Pivot Technologies"

Our clients are often pushed to adopt new technologies to accommodate political or financial time lines. More and more, we find that our clients are pushed to move from one paradigm, system or methodology to the next one in a single, terrifying leap.

In fact, I wrote a post about that a little while ago which you can find here if you are so inclined. The executive summary in this context is simply that making technology transitions can be done faster, safer and better with evolution instead of revolution, with smaller, well-defined steps instead of jumping out of the airplane, pulling the rip cord and praying for a soft landing.

So if large leaps of faith make me queasy, what do I propose instead? I propose what I call "pivot technologies." To me, this term means technology which can operate in more than one mode. In practical terms, I mean stepping stones from one technology or methodology, which is being phased out,  to another replacement technology of methodology.

For example, in our consulting practice we often provide on/the-fly translation from one set of codes to another set of codes. This allows users to enter transactions from the old set of codes into the new information system.

Until recently, getting approval for pivot technology projects was relatively easy; technology shifts were common and everyone understood that pivot technologies were cheap insurance against painful transitions or even failed transitions.

Recently we have run into a new conventional wisdom. Now we hear that pivot technology projects are a bad idea for two reasons: they are a crutch and they never go away.

Executives say pivot technologies are a crutch because they enable users to avoid making the mandated transition. I am not clear about how easing a transition is the same as impeding it, but there you are.

Executives say that pivot technologies never go away; I assume that the point is that one ends up with an environment cluttered with no-longer-needed pivot technologies which are never retired and cleanly removed.

It is true that I have seen that vicious cycle: a pivot technology is rolled out a crutch, then the transition to the next technology falters, or is even held up by people clinging to the pivot, then you have the pivot but not the transition. But that scenario is not inevitable; indeed, it should not even be likely. After all, the whole point of deploying a pivot technology is to have greater control over the transition, not have less control or no control. So make a plan and stick to it. And cover your bets with a pivot: you might be able to jump the stream in a single bound, but why take the chance?