And there was sadness round, and faces bowed,
And woman’s tears fell fast, and children wailed aloud.
On any software project, the development time and cost, as well as the amount of weeping and gnashing of teeth, will increase geometrically with the number of abstraction layers.
That’s why it’s called “n-tear development.”
Thus spoke The Programmer.
Notes from the Rainbow Hotel Casino, Wendover, NV:
Belongings in a U-Haul in the parking lot.
I liked the Bay Area, but it was indifferent to me.
I sold online ads for an Internet company. I wore shorts to work and still made a lot of money.
Then in October, the executives called a meeting and told us the company was closing. We had an hour to leave the building.
I was really sad.
I got another job selling ads for LookSmart. But LookSmart wasn’t as smart as it looked. In January, they laid off 30 percent of the staff, including me.
There was good news too. I could always find 12 friends to go bowling on a Friday afternoon because they didn’t have jobs either.
Now I’m going B-to-C.
Back to Cleveland.
Ansel Adams was born on this date, Feb. 20, in 1902. Adams was a great American photographer, best known for his black-and-white photos of Yosemite and other natural monuments of the American West.
Men at some time are masters of their fates:
The fault, dear Brutus, is not in our stars,
But in ourselves . . .
The Programmer finds that the integration chickens have come home to roost . . .
I remember when Vignette first arrived at our company and the people who had made the decision to buy it would show up at meetings in their complimentary Vignette polo shirts and explain that the project was going to be delayed just a bit more because they still couldn’t work the bugs out of the Vignette installation — but hey, willya look at these free shirts we got?!
Well, we’ve been trying to work the bugs out of it for three months now, and to integrate it with IBM’s WebSphere for a client project.
We tried Vignette 5.5 with WebSphere 5.1, which didn’t work. We tried Vignette 5.5 with WebSphere 4.1, and that didn’t work either.
Through it all, we clung to the hope that the upcoming release of Vignette 5.6 would solve all our problems by working — as promised — with WebSphere 5.1.
That is to say . . . even though 5.6 hasn’t been officially certified by Vignette to work with WebSphere, the rep who provided the free shirts told us that he personally thinks it will work, so we’re counting on it.
And . . . it doesn’t work.
The failure of the 5.6 release has been a horrible psychological setback, and there has been mourning and lamentation.
“We trusted them . . .”
“If this is how they treat their friends . . .”
But . . . if we were to indulge in a moment of introspection, search our conscience, we would have to admit that this is a risk we incurred when we elected to create the dependency on Vignette — that Vignette might somehow drop the ball, that their next release might be a piece of crap, that they might change their product strategy, that they might fire the remaining 85% of the workforce and go out of business entirely, any of which would be a body blow to those of us who’d elected to build web sites around their technology.
It’s like handing a loaded gun to a trained ape (and a poorly trained ape at that). When something goes wrong, you can’t blame the ape.
It’s a way of living with a tragedy, I guess, to claim after it happens that you saw it coming, as if somehow you had already made the necessary adjustments beforehand.
Sycophant: You saw this coming.
Project Manager: Big time.
Well, Mr. Project Manager, it’s not even something that was coming . . . the whole project from Day One has been an integration nightmare. And there’s really no credit in having seen something coming if you did nothing to avert it. It makes people think that maybe you didn’t see it coming, or if you did, that you grossly underestimated the severity of the problem, or you didn’t care, or you thought you could bluff your way through it.
Integration of third-party products is always hard and best avoided.
The problem isn’t specifically with Vignette or Websphere. Substitute your own favorite “best of breed” solutions; the issues would still be the same.
Thus spoke The Programmer.
Saw a license plate in the office lot today on a BMW 535i:
On the frame, it said “Hey Boys — This Girl Will Die With The Most Toys.”
Cast of Characters
Manager, the leader of a software project that is floundering because his needlessly complex design cannot actually be implemented.
Programmer, a programmer on the project.
Manager: Keep working hard, and I will protect you should things break down.
Programmer: Protect me from what? That sounds kind of ominous.
Manager: Some people may be worried that if the project fails, they may get a bad review, or not get a bonus. But I’m looking at whether or not people are working hard, even if the project isn’t going well. So as long as you’re not goofing off, and you don’t have a bad attitude, you should be all right.
A “bad attitude” in these cases is defined as pointing out that 20 people have been working on the project for two months without producing a single working line of code, because they’ve been asked to yoke together a set of incompatible products and technologies selected by people who are not qualified or interested in assessing the technical implications of their decisions.
This, unfortunately, has become an increasingly common scenario in our business.
I should also mention that, in my experience, people are highly demotivated by opportunities to work hard in situations where they are predestined to fail.
But don’t worry! As long as you’re willing to keep beating your head against a stone wall of incompetent management, you’ll be as safe as Humpty Dumpty . . .
‘Why if ever I did fall off — which there’s no chance of — but if I did … Here he pursed up his lips, and looked so solemn and grand that Alice could hardly help laughing. ‘If I did fall,’ he went on, ‘the King has promised me — ah, you may turn pale, if you like! You didn’t think I was going to say that, did you? The King has promised me — with his very own mouth … to … to … ‘To send all his horses and all his men,’ Alice interrupted, rather unwisely.
Thus spoke The Programmer.
I’d never heard of TheMan.com until yesterday, when I read that the site had shut down, and replaced what I assume must have at one time been content with the resumes of its out-of-work former employees.
You can get a good feel for the company from this Sept. 27, 1999 Time magazine article.
Cringe in horror as moronic 27-year-old CEO Calvin Lui closes meetings by barking “All right, dudes, let’s rock and roll!’
Gasp in amazement as he draws analogies between TheMan.com and one of his former employers, the Walt Disney Company! “This could be a major, major public company,” he says. Not a major public company, but a major major public company!
Feel his soul-stirring passion to recruit “the A people” for”‘below-average salaries”!
Lui was right about one thing though: “I understand that right now we’re a zit compared to everybody else. But in a year, we’re not going to be a zit.”
What did he think they were going to be? A cyst? An abscess?
Well, no matter. The important thing is that now you — yes, you! — can duplicate Lui’s spectacular results by adding some of his underpaid A-Team to your own staff.
Act quickly!
Are you looking for a Lead Web Developer? Consider William Huang. According to his resume, Huang held the title of Lead Web Developer at TheMan.com, Inc., for the past year.
He has no other programming experience, but he does have 4+ years of service as Assistant Manager at the Corridor Center 55 shopping center, where his responsibilities included:
So if you need a Web developer who can also sweep up, look no further.
Huang’s resume lists no educational background, but that has not prevented him from achieving proficiency with WS_FTP Pro. That will come in handy if you have a need to move files around from one server to another, as many companies do!
His resume also states that he plays both basketball and volleyball, if you ever need to get up a game.
I don’t know who said that. But I know there was a time not too long ago when you couldn’t even get hired as a trainee in this business without at least having a college degree.
Of course, at that time no one really believed you could hire “A people” for below-average salaries.
Serious, responsible companies lived or died with their data, so they hired serious, responsible people to work with it, and they paid them an appropriate wage.
Tempora mutantur nos et mutamur in illis. The times are changed even as we are changed in them.
Thus spoke The Programmer.
The Winchester House in San Jose was built by Sarah Winchester, heiress to the Winchester (“The Gun That Won the West”) Repeating Arms Company fortune.
After her daughter and husband died, she came to believe that the family was haunted by the ghosts of people killed by Winchester rifles.
She consulted a medium in Boston, who told her to move west and build a mansion that would never be finished.
As long as she kept building, she would never die.
(Whether or not you believe in spiritualists, you’ve got to give high marks here for originality.)
In 1884, Mrs. Winchester moved to San Jose, which was then a rural community, and bought an eight-room farmhouse. She kept builders employed at the house 24 hours a day for the next 38 years, until her death in 1922.
By that time, the house was four stories high (it had been seven stories before the 1906 San Francisco earthquake) and had 160 rooms.
Of course there was no master plan for all this construction. Mrs. Winchester had a seance room in which she consulted “good spirits” for architectural advice.
Mostly she was building for the sake of building, per the medium’s advice. As a result, the house is full of structural oddities: staircases that lead nowhere, doors that open to walls, fireplaces without chimneys . . . a classic case of ineffective change management.
I originally developed the idea of a Winchester House Effect in software in collaboration, I guess you could say, with a former colleague of mine — shortly before he went insane.
He was a project manager on a project that had fallen behind schedule, so he decided to jump in and do some coding in an effort to make up for lost time.
He unwittingly wound up trying to code the most complex program in the system, the one the rest of us had been trying to avoid.
In retrospect, I wish we’d tipped him off to maybe start with something a little simpler, but there was really no way to foresee the effect the program would have on him.
His behavior became increasingly strange and paranoid. He wound up leaving the project suddenly, although not before finishing the fateful program.
The code was bizarre; the program flow made no sense. I remember thinking at the time, “He’s created the Winchester House of software.”
His subsequent hospitalization was (we were told) for high blood pressure, and not — not — the result of a nervous breakdown.
The program was unmaintainable and was eventually rewritten from scratch.
Action is eloquence.
Vicious, despicable, or thoroughly disliked persons, gentlemen, and ladies can be project managers. Lost souls, procrastinators, and wishy-washies cannot.
You can have a lot of bad qualities and still be an effective project manager, but you can’t be indecisive. Work out your personal insecurities on your own time.
Make a decision. Move on to the next problem.
Thus spoke The Programmer.
Most of my illustrious career has been spent working or consulting for Fortune 1000 companies. These companies are fundamentally dependent on their computer systems, particularly their online systems, to transact business.
If the systems are down, the business stops running.
In fact, the systems don’t even have to be down to create havoc.
What if the response time is too slow? If you’ve ever done user testing with people whose job it is to enter money-making financial transactions for large corporations, you may have been amazed, as I was, at how fast they are.
Obviously then, the software you build for them has to be even faster; split-second response time is required. If your software is slowing people down, the business is losing money.
Or what if people are sitting around staring at their monitors because they can’t figure out how that great new interface you gave them is supposed to work?
Bad news.
Again there’s a measurable loss of revenue. Because these people are not supposed to be staring at their monitors, they’re supposed to be entering those money-making financial transactions, remember?
I could go on with this, but I think we both get the point: As a technologist working with these companies, you’re held to an exacting standard, because the cost of failure is high.
One evening many years ago, I put a software upgrade into production for a client, a major electronics distributor.
It was a pretty straightforward upgrade and we tested it, but I guess we didn’t test it diligently enough on certain boundary cases, because when I came in the next morning, I was informed that our “upgrade” had crashed, preventing the online system from coming up for an hour until it could be backed out and order was restored.
In other words, we had effectively put the company out of business for an hour, a really expensive mistake. I was further informed that the CIO wished to talk with us in his office once he was finished getting his ass kicked by executive management.
Well, my dick was limp, I’ll tell you.
I took a moment to divide the company’s annual revenue by the number of business hours in a year. According to my calculations, this fiasco had cost about $250,000.
I popped another Xanax and washed it down with a pot of coffee to keep from passing out. I was twitching like a chicken for hours.
Yes, and thanks to experiences like that, I now consider myself a seasoned developer. I try to anticipate the consequences of technical decisions early in a project in an effort to avoid downstream catastrophes.
But I don’t work on mission-critical applications now.
I work on Web applications.
And with different kinds of applications come different kinds of developers.
Most Web developers have worked exclusively on systems where the cost of failure is very low, so they rarely ponder the implications of technical decisions in great detail.
Why bother? What’s the worst thing that could happen?
Well, the Web site could have unpredictable access times, it could scale poorly, users could be unable to navigate the interface.
But so what?
As I write this, people still expect Web sites to have unpredictable access times, to scale poorly, and to have confusing interfaces.
Developers aren’t penalized for this; it’s all factored into the equation, as though improving the situation is beyond human capacity.
He who pays the piper is calling for a low-quality tune.
Okay, part of the problem is that most clients either don’t know any better or aren’t willing to pay for better.
And, you might say, why should they when users are still more than willing to forgive them for mediocrity?
But here’s the real problem:
Very few Web developers have had the edification that comes from blowing away a quarter of a million dollars of someone else’s money in an hour, not to mention the resulting shitrain that descends over the land.
Because if they had, they’d be a little more careful next time.
Here’s a fun story about the benefits of really holding people accountable for shoddy workmanship.
In The Innocents Abroad, Mark Twain wrote about King Xerxes, who in the 5th Century BC ordered a bridge of boats to be built across the Hellespont:
A moderate gale destroyed the flimsy structure, and the King, thinking that to publicly rebuke the contractors might have a good effect on the next set, called them out before the army and had them beheaded. In the next ten minutes he let a new contract for the bridge. It has been observed by ancient writers that the second bridge was a very good bridge.
Res ipsa loquitor.
Thus spoke The Programmer.
