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?

Leaping Into The VOIP

Recently we shifted our company from Plain Old Telephone Service (POTS) to Voice over IP (VoIP). To my surprise, even though designing, creating and deploying new technology is our business, I was a bit apprehensive. I am assuming that this is a valuable reminder of what it is like to be on the other side of the table.

POTS is what telephone service has been since it was conceived: copper wires carrying signals from one telephone handset to another, with lots of switching and amplification in between.

I was comfortable with POTS, with faxes, with modems, with copper wires and splitters and the like. When we built new offices some 15 years ago, I had made sure that there were plenty of phone lines coming into our office: some for our internal PBX (that thing known to most as "the phone system"), some for our fax machines, some for our modems.

I was so comfortable with POTS that this transition was put off for a really long time and much of it happened when I wasn't looking.

Over the years, faxing migrated from special purpose fax machine hardware to fax servers and the like (Open Source fans that we are, we used HylaFax). We still needed a fax line, but not so many.

Broadband Internet access and the rise of Virtual Private Networks (VPNs) pretty much killed the need for modems as a way to access client resources from afar, so we stopped using them, even from the road.

The jump to smart phones had been carefully planned: we waited until we felt that they were mature enough to allow us to abandon our Personal Digital Assistants or PDAs (we were using Palm devices) to hold our contacts, handle our calendars, keep our secrets and track our billable time. Once smart phones could do all that, we went to smart phones instead of mobile phone + PDA.

When we finally adopted smart phones (we decided to go with iPhones for a variety of reasons), we suddenly found our desk-bound phones to be kind of a drag. We wanted to deal with only one phone system, but we didn't want to give our mobile phone numbers, nor did we want to lose the basic business functions of having a central phone system.

So we decided to go with a virtual PBX from RingCentral. This gives us the PBX features, but we can also run their smart phone app and use our smart phones as business handsets as well. So our business calls follow us around (during business hours) and I have reclaimed some precious desk space from the hulking handset. Our faxing is also handled through our virtual PBX.

It has been a couple of months now and we are very happy with the lower overhead, the feature set, the convenience and the greater access to our voice mail and our faxes. The computer room is much tidier without all those phone connections, the old hardware PBX and the line conditions, etc.

So why was I apprehensive? It was not the change to VoIP: I know that technology inside and out. In a previous incarnation, over ten years ago, I got Net2Phone's protocol up and running on a VoIP phone we were developing and their tech folks to whom I demonstrated it were very impressed as I was the first external person to get their protocol working on a non-computer. I spent hours making phone calls using VoIP and writing software to support VoIP. I am comfortable that the technology is even better now.

It was not the cost:benefit analysis which our operations person did and clearly showed that it was time.

Upon reflection, I think that it was inertia and simple unreasoning fear of change. Exactly the sort of thing that I have to fight in my clients when I create new technology for them to streamline their processes and better integrate their systems.

I respect fear of change: careful consideration is a good idea before every big decision. I understand better than most that not all change is good and that tearing apart the present does not guarantee that you will assemble a better future.

But I don't respect procrastination or paralysis by analysis: may God grant me the wisdom to know the difference.

Doing Without For Now

In these fiscally strapped times I am seeing a resurgence of an old financial misunderstanding: that not spending money is the same thing as saving money.

I understand that one should not spend money that one does not have. I am not advocating deficit spending, accounting magic or blowing your budget. Instead, I am advocating responsible investment.

Too many managers I encounter are rewarded for simply failing to spend money, or fear being penalized for spending money. Being "under budget" implies that you met the organization's goals by spending less than expected. This means either that you are good at getting results or bad at making budgets. "Failing to spend money" is not the same as being under budget: if you don't accomplish your goals, then you are failure who at least didn't waste money while failing.

But simply avoiding investment for the sake of not spending money is not fiscally responsible: it is the opposite of fiscally responsible. To make decisions without regard to future benefit is a mistake. If you want to go down this path, I can save you some time: this analysis leads to paralysis. Using this philosophy, you should never spend any money or take any action: not spending money will leave you with more immediate cash and not taking action will avoid mistakes. Just ignore the fact that not spending money can lead to lack of future money and not taking action can lead to not having a job.

To take a rather tired example from home ownership, not repairing a leaky roof gives you a short-term benefit (your bank account retains the money that you would have spent on the roof) and a long-term liability (your bank account will be hit much harder when the roof and collateral damage become so great you can no longer ignore them.) By the same token, if you don't choose a contractor, you avoid choosing the wrong contractor. So you have that consolation as your roof falls in.

I run into this same behavior in business fairly frequently, in the guise of the following sometimes reasonable statement: "we know we need X, but we’ll get it in the next release / next version / next purchase, so we will do without it right now."

The useful life of most of the systems I encounter is between three and five years. If you put off the decision for a year, you have lost much of the benefit the system can be expected to provide. If you put off the decision for two years, your potential loss is that much greater.

If your investment is a reasonable investment, you are missing the return on that investment every year you defer. In real terms, not spending money, if you spend it wisely, is actually costing you money.

When we speak of IT investments, we speak of more than dollars: IT can provide automation which makes your personnel more productive and less harried. With the time not spent in drudgery that should be done by a machine, your people can actually think about their jobs and improve their situation.

There is also the experience factor: if you make investments early and often, you can often make smaller, incremental investments and be guided by actual experience as you move toward your goal, instead of being guided by marketing literature as you wait until the last possible second and then leap onto a bandwagon.

I have heard a cogent counter-argument from reasonable people, which runs something like this:

• IT transitions are risky, even if done well
• There will be less risk if there are fewer transitions
• Fewer  transitions means bigger ones farther apart
• The individual transitions might be more painful but ultimate time line is shorter and the new systems end up with a bigger footprint

I can see how one feel this way, but I just cannot agree: in the evolution versus revolution debate, I still come down on the side of evolution. Revolution leaves too little room to correct bad assumptions or changing circumstances.

I sympathize with the claim that larger organizations have such deep tendencies toward inertia that multi-stage plans are scary. But leadership requires actually taking reasonable risks instead of simply avoiding blame.

Hard vs Soft Mastery

Some years ago, as part of a discussion of computer programming styles, a colleague introduced me to the concept of "hard master" versus "soft master." Be warned: I am emphatically not making any value judgments here: I do not believe that hard masters are smarter, purer, better or more detail-oriented. I do not believe that soft masters are failing at being hard masters; I do not believe that a good hard master can do anything a soft master can do, or vice-versa.

Enough about what I don't mean: what do I mean? A little Google magic got me here, the horse's mouth: Feminism Confronts Technology by Judy Wajcman. Read the selected section for details, but the summary is this: the hard master feels he has to know all the details when using technology while the soft master knows how to get what she wants.

The use of gender-specific pronouns is not accidental: frequently hard masters are male and soft masters are female. Note that while there is a significant pro-male, anti-female bias in computer programming, this is not a bias from which I happen to suffer. I have worked with women for my entire technical career, and have found female technology interaction different but not inferior. In fact, I have found that this discipline has room for, and needs both, kinds of interaction. As a general rule, I want my bit-bashing systems software from an anti-social grumpy guy and I want my application software from an empathetic, flexible and cheerful gal.

I understand that these generalizations are not universal truths, that there are grumpy women who are antisocial and mathematical while there are cheerful men who are sensitive to how technology feels to use, and all possible permutations in between.

But I do not believe that all permutations are equally probable. I find distinct trends: men tend to define technological success and men tend to be hard masters. Women have their own technological approaches and these approaches tend to be deemed inferior by men, mostly men who cannot perform these "soft" tasks themselves.

Given this observation, I was not surprised at a recent recommendation of related reading from another colleague: an article from the Harvard Business Review that considers the assertion that women make your technical team smarter. I am sure that is true, at least for my team.

In the interests of full disclosure, I will admit to being a middle-aged man who thinks of himself as a designer, as something of a non-combatant in this fight. My attitude is that I can code anything I have to, but I am not a coder. Opinions of my coding by coders varies, but mostly I think that both hard and soft masters have reason to despair at my code. So I claim to be of neither camp: I need them both to get my designs realized, unless I end up having to code one or other kind of task myself. Which happens all too often in these recessionary times.

I find the hard versus soft dichotomy in server software versus client software. For example, configuring a web server is a heavily technical task which requires a deep understanding of networking, process management and security. By contract, creating a web page is also web-related, but has utterly different requirements, including a flair for graphic art and an understanding of usability.

I also see this division in the back end (data storage & retrieval) area as opposed to the front end (data acquisition through user interaction) area. Figuring out how to store data effectively is a job for a hard master who wants to think about file systems, database formats and the interaction of caching and performance. Figuring out how to get users to enter data quickly and accurately is about understanding how human beings use software.


From my perspective, there is trouble brewing for the hard masters. It is my observation that as abstraction rises mastery softens. When there was only simple hardware, Unix and ANSI C, someone could be a hardware expert, a firmware expert, a Unix system software expert and complete master of their own code base. Now, with server clusters and interpreted languages and database interfaces and web servers and programming environments embedded in web servers, I just don't see that as a viable or desirable goal. How do hard masters get anything done these days? They must have to restrict themselves to rather small areas of expertise.

Not only is abstraction on the rise, but I see a very real trade off between productivity and mastery which abstraction provides. Women who are happy to cruise along at the GUI-to-create-GUI level, such as Visual BASIC, kick my ass in terms of how fast and how custom they can make apps. Who cares how deeply they understand what underpins that abstraction? (Until that abstraction bites them in the butt; more of that anon.)

There has been a shift in the balance of power between apps creators (soft masters) and systems engineers (hard masters) as time has gone by. So far as I can tell, app programmers now rule: users understand what they do (create apps), economic buyers are willing to pay for what they do. Also for systems engineers, I find that users have no idea what they do, economic buyers don't relate to them or their work and organizations feel that they get the behind-the-scenes stuff for free, as part of buying apps, or smart network hardware, or whatever.

When I started out in the early 1980s, app programmers were the bottom of the ladder, while systems programmers did the real work, got paid the real money, and wrote apps whenever they felt like it. As a designer, I find that I no longer have to start by getting hard masters to buy into my design: in fact, I find that most of my gigs come from soft masters coming to me so that I can create a framework in which they can create the apps that people want. No one is interested in the lowest levels: is this MS-Access to a local database, or MS-Access as a client for a database server? Who cares?

Of course, users should care: bad infrastructure makes for a bad user experience. But users don't care about boring old infrastructure and systems engineering because most of the time they can afford not to.


All this does not bode well for the hard master. These days, I see hard mastery in demand only in those relatively rare instances when the abstraction fails or is incomplete. When you need a DLL to extend the Microsoft desktop, or a shared object to extend the Perl interpreter, you really need that. But how often does that come up? When I started out, we had five or six programmers, all male, two of whom were apps specialists. Over time, we have tended to add apps programmers, who tend to be women, and we have moved to consuming our hard mastery as a pay-as-you-go consulting commodity: we don't need full-time hard masters anymore.

This makes me a bit nervous: will the hard master be there in the future when I need him? But for now, I am busy being part of the problem: I need more soft masters and fewer hard masters I don't see that trend reversing anytime soon.