Back in the early 80s, I worked with a technician who told me a story. It goes something like this: (Names withheld)

The technician was working with an engineer on a water desalinization system. The engineer asked the technician to "ground point B." The technician tried to tell the engineer that "point B" was the main power feed. The engineer wouldn't listen, and insisted that the technician just do what he was told.

So, grabbing some gloves and eye shields, the technician taught the engineer a lesson. He grounded "point B."  The system mains and the building's main feed blew. (desalination systems need a huge power feed.) I also recall that the streets transformer took a hit.

Moral of the story, well, that's up to your own interpretation. Should the technician have tried harder? Should the engineer have listened? Is it about a working relationship were authority is used over merit? Is it about poor documentation? Lack of communication? Who knows?

I think about this story frequently in conjunction with my last job. I generally like start-ups because I am probably a compulsive gambler. I don't like lottery tickets, I like a game where I can influence the outcome. Startups can be like that. I have yet to hit a winner, but, I think I was close 9 years ago before September 11, but down with the buildings came my dotbomb. Yet, I keep trying.

The last startup in which I was involved, had all the looks of a good bet. An interesting product with a lot of potential. The initial offering and feature set should have been attainable, and from that, the sky should have been the limit.

Unfortunately, myself, and 4 or 5 other engineers (almost 80 years combined experience) were not to design or build the product as our years of experience and expertise would have directed us. The product's architecture and construction was by management directive. Why hire experienced and proficient people if you do not accept their knowledge or judgement? OK, one oddball could be a trouble maker, two odd balls may be statistically insignificant. When all the senior technical staff say that something is a bad idea, why are such warnings ignored, even contemptuously brushed away?

For example, one of the things we were told that while we need to analyse data, we were not allowed to use a database library of any kind. The management didn't want to have any databases. We actually had to hide a database in the code to get the work done in a reasonable amount of time. Our name for the data layer was “nsl,” for “not sqlite.” While this is not an advertisement for SQLite, I would say that it would not have been possible to meet deadlines without it or something like it. Otherwise, we would have had to come up with a shared data storage/analysis model that could be used by multiple environments like Java, AIR, and C/C++.

I could go on and on in a “he said, she said” manner, but suffice to say, it didn't work out. The product was a failure for many reasons. Engineering had a revolving door with key people leaving on a regular basis. After about a year and a half, they shut down the project. I've never really been in that position before as I've always managed to get things to work. I was the last engineer on the code base not to quit, I was let go.

The moral? I don't know if there is one. We all tried to improve the situation. We all tried to get it right. I guess work is like marriage, sometimes they work and sometimes they don't. When they break up, it's usually someone's fault, but at the core it was a bad marriage.