Tag Archives: business

Business Loss: Is That A Spade I See?

The other morning on the televised news I heard of (yet another) corporate muckety-muck drawing a comfortable salary (USD6M, in this case) despite their company’s recent losses (some USD40B). And it got me to thinking about terminology.

Take the term from which this entry derives its title: ‘loss’. I’m thinking that this is one of the most misused terms around – especially today, as it applies to business and economics. It seems to be deliberately chosen to create a feeling of sympathy for the ‘lossee’, and I think that the feeling is completely misplaced.

Let’s first look at a perfectly accurate usage. “Joey Psychotic lost his home and all of his possessions to fire this morning, believed to be started when his hungry cat kicked over an unattended prayer candle…” This makes sense – Mr. Psychotic had a home. But it was consumed by fire, reduced to a wet, smoking pile of rubble, crawling with investigators. Not a home by any stretch of the imagination. You feel sorry for Mr. Psychotic, and you should (even while questioning his religious rituals).

Now, how about this one: “The Acme Prayer Candle Company lost forty billion dollars over the last three quarters of this year due to slacking demand. Stockholders fear bankruptcy as…” Nope, I don’t buy it. That which you do not have cannot be lost. Acme didn’t lose anything – they never had it in the first place. See the difference?

Let’s take a stab at writing that a little more accurately: “The Acme Prayer Candle Company failed to realize forty billion dollars in profits over the last three quarters of this year. Acme executives cite slacking demand as the cause of their failure to deliver promised value to stockholders, who fear bankruptcy as…” Acme didn’t lose, they FAILED.

Fail brings a whole different set of emotions than loss. It’s not that failure is necessarily bad, either. After all, failure can be a very powerful teacher – well, provided one can grasp its message, which isn’t a given.

I don’t feel much sympathy toward anyone that can (mis)direct their company to failure, and yet still pull down six million greenbacks. I won’t bet on their learning anything, either, unless it’s something along the lines of, “hey, look what I just got away with!”

Maybe the companies that are failing should be allowed to fail, their directors along with them. A multitude of companies, built on good ideas, managed competently, would certainly spring up in their place. I’m not denying that there would be great steaming heaps of economic pain along the way, the likes of which most alive today have never seen.

But America, still the greatest land on Earth, would emerge stronger than ever.

Standards and Documentation

 

[This entry is lifted verbatim from a message I recently wrote in email to a good friend. We were idly discussing a bit of documentation that one of his technical writers had produced, when he commented that he created his own standards: whatever he said, so it would go. He concluded, “It’s good to be the king, sort of…”]

I was lapsing into the way things used to be. Once upon a time there were Standards for everything.

Here’s a funny story. There’s no real proprietary stuff here, but it sheds a teeny tiny bit of light on the seedy underbelly of a company that would probably prefer otherwise.

Back in the 80s and before, there was a Standards Department. A handful of folks: a few writers, a few managers, a room of shelves with binders. (This was, of course, pre-LAN, pre-email, pre-all-the-stuff-we-take-for-granted-today. They walked floppies to a PC that was connected to an IBM line-printer. This was modern; not much earlier they used typewriters. The IBM ball-headed devices – were they called Quietwriters?  Selectrics – were still around.)

I hear you saying, “roomful of shelves with binders? Golly, what could they be documenting?”

Back then, every system, every subsystem, every sub-subsystem, every database, every data feed, every EVERYTHING was custom-built for a specific purpose – be it another system, a customer, whatever. This was before all the wonderful acronym-laden standards for such stuff we have today. (“I love standards – there are so many to choose from!”)

Anyway, time passes and in comes LANs and email and all kinds of magic and, one day, they went and dissolved the Standards Department. Figured that the Programmers could write their own documentation. Out went the writers, one by one. Then the managers. Their equipment was collected and taken away and their space was re-allocated. But not before I scoured their PCs for their documentation files. Thousands and thousands of Word docs. Stashed ’em away in a big zipfile, I did.

Then there was the room full of shelves of binders. A girl I knew, a minor manager, was given the mandate to keep the lights on.

So the years passed. Major systems were rearchitected to common standards. New products were created. The outsourcing wave washed upon the tech shores. And lots of old talent – along with the knowledge of how the proprietary systems worked – was shown the door.

Along came Y2K, at first just a glimmer on the horizon. With the massive technical audit that was undertaken to prepare for that event came the realization that quite a bit of the shiny, new, “self-documented” code was critically dependent upon… wait for it… bits of old legacy stuff that nobody knew anything about anymore.

“Wait!” someone said, “We’ll call the Standards Department! All this stuff is documented!”

Uh oh.

It took a while, but eventually it was realized that the Standards Department had been decimated the better part of two decades earlier. Some hand-wringing later they discovered the roomful of shelves of binders. It had been dutifully passed along from hand to hand through several reorganizations, relocated over 2-3 facilities moves, but there they were. Unmaintained. Disorganized. Dusty. Thick, blue, three-ring binders, labeled with crusty, cryptic strings of numbers and letters – if you were lucky. Some had fallen off with age. But descend upon the room they did, borrowing one volume or another as the analysis plodded onward.

I remembered the original room, the old Standards Department, and when I heard about this I smiled. But when I heard that as often as not the borrowed volumes weren’t being returned, my smile turned into a frown. I grabbed control of the room, had it locked, began to mediate access. Soon I was doing a brisk side business as a librarian. I blew the dust off the forgotten zipfile and got the content onto the network. After all, it’s way easier to content-search a tree of files than to traipse over to some other building an spend hours with those dusty old binders. Or sign your life away to the shaved-head dweeb that made sure you brought ’em back. Trouble is, the files and the binders ain’t exactly one and the same all the time.

And then, there’s the stuff that no one, try as they might, could find documented ANYWHERE. Several thousands of those entities were scattered across the organization. Little black boxes, you can see what goes in and comes out, but haven’t got an inkling of what goes on inside. Except when one little black box talks directly to or from another little black box, hmmm, then you don’t really know much about the interfaces either. Quite troubling.

Y2K came and went – rather uneventfully, actually. The world didn’t end. The systems actually came out the other side better than they went in. Life went on. Interest in the room and the files waned, but didn’t go away. As it turns out, Programmers, especially contractors, especially hourly contractors with lots of churn, aren’t exactly the best when it comes to documenting their work. And “self-documenting code” really isn’t, unless the reader is quite technical. The legacy stuff, well, the stuff that’s actually documented, turns out to be the best documented stuff there is. Created by people whose job it was to make it so.

Now here’s the punchline. To this very day, if you dig deep enough, through the shiny, new Web-enabled, SOAPed and serviced layers, you could very well discover dependencies upon some bit of legacy code or another that *nobody* understands, code for which there’s *no* source code, *no* documentation…

This is a good time to end the story, as we sit and sip our morning coffee, pondering the sinking feeling in the pit of the stomach of some poor sod somewhere whose unfortunate lot puts them near one of those bits of code.

Business Licensing in My Town

Starting a new business is, among other things, an exercise in discovering exactly which licenses, permits and permissions one needs to obtain. My local municipality requires such a license. The application consists of a one-page form and payment of fifty dollars. It seemed simple enough.

The municipality has a decent Web site. Some might argue that the layout is hard to navigate but it doesn’t bother me. In short order I found several links to the required form. The trouble – you guessed it – none of the links worked! I played good citizen. I compiled a list which included a few other dead-ends I discovered in my quest and submitted a report. The next day my inbox held a reply. But what do you suppose I found when I returned to the site? The questionable links had simply been removed!

Following a couple of days of no progress I decided to visit the Municipal Complex in person. Just before firing up the motorcycle I checked the site for the proper form name and… what’s this? A restored link and an available form!

I pulled the downloaded PDF into an editor and went to work. Some questions struck me as odd but what the heck. I printed the result, cut a check, stuffed the envelope and sent it on its way.

In a couple of days I had voice mail from the town. We actually played phone tag for a couple more days. While playing I even tried to stop by the office twice to no avail. This was dragging on too long! But finally we made contact. Uh oh, the news wasn’t good. It looked for a moment like my application would not be approved! (Er, no mention of why my check was cleared several days previous.) Some polite conversation cleared up the issues and approval became certain. We ended with an upbeat discussion of technology and an introduction to the IT staff. Close call.

Fast forward several weeks. My license had arrived! What a disappointment. I mean, I print way better quality draft material from my inkjet. Half a colored sheet of crap-quality plain paper, n-th generation photocopy with a couple of fields inked in, they couldn’t even cut the bottom of the thing parallel to the top. To call it sloppy would be a huge compliment.

Oh well, it had a number and an official seal. And I guess that’s all that matters.