Fog Creek Software
Discussion Board




In Search of Stupidity : bonehead programmers

In the 80's I worked for Hunter and Ready, which became Ready Systems. In 1985 when I came onboard as a Field Apps engineer in the Sales department, H&R arguably was the leading vendor of real time OS's for embedded systems.

There was a core team of SW engineers who had been doing the engineering for a while. They had strong beliefs about the purity of the kernel and the architecture and  features it should have. Unfortunately those beliefs didn't match up with what the customers wanted.

Time and again we went on sales calls, and customers would say, the pSOS guys have deterministic scheduling and variable blocksize memory allocation and feature X and feature Y etc. You don't. So we are buying PSOS. (the 'deterministic' scheduling thing was a bit of a red herring, but it took a lot of tech explanation to show what we had was just as good and maybe better for small embedded systems, but that ended up being a hand waving excercise. It never convinced anyone).

The salesmen and engineers in the sales team would go back to hq and beg for at least the two main features but the purist engineers flatly refused to implement them or anything else outside their vision. Even when the president of the company ordered them to do it they simply refused and since they were the core team, what could anyone do?

From 1985 to 1990 when I left, there was a slow downward slide in sales until the company was bought out and ended up a shadow of its former self, with almost no market share. Maybe it was my fault since the downslide coincides with my tenure there.

Anyway my point is that programmers will make really stupid decisions just like the marketers will. Maybe the real issue is that most people make stupid decisions most of the time.

david howard
Friday, August 22, 2003

Hunter and Ready produced the VRTX RTOS.

david howard
Friday, August 22, 2003

True. But I suppose the reason behind the latest rants in this forum ("Managers vs. Techies") is that some programmers got the impression that managers are more likely to be resistant against any consequences when they make mistakes.

Johnny Bravo
Friday, August 22, 2003

I'll buy that, given the different personality types.

david howard
Friday, August 22, 2003

Sounds like they are OSS material.

m
Friday, August 22, 2003

They may have been technically right in refusing that feature request. But apparently, marketwise wrong.

But I wouldn't pull too many conclusions from this story - there are hundreds of reasons for things to go wrong. From how you tell it, it seems like there was not even one feature in your system that was not available in pSOS -- one that the sales people should have, and could have, capitalized on.

What about the price?

What about the environment? Things like having an IDE + debugger + simulator  etc. could do a lot to product acceptance.

I've been in many sales meetings, and one conclusion I'm pretty certain of is that you can't trust your client to tell you their real reasons for not adapting your product, and in many cases, to actually know them and admit them to themselves.

Ori Berger
Saturday, August 23, 2003

I remember evaulating VRTX and pSOS for a project and feeling like it was a toss-up.  I selected pSOS but it was for features that I considered "candy". I could have just as easily adopted VRTX, no big deal.

I find it hard to believe that "mere" SW engineers could have shot the company in the foot.

A contrarian point of view: the marketing and sales of VRTX wasn't that good and the engineers were keeping a well focused product that they could support and guarantee to work well?  Many SW companies are whipsawed by marketing demands into "featureitis" and producing crap. Maybe these guys were trying to avoid this trap? After all, one expects (demands) that embedded stuff be absolutely reliable.

I'm not sold that it was the programmers' fault that any company goes downhill. Ultimately, it's up to management to prioritize things, including calling the bluff of employees who are being insubordinate.

Bored Bystander
Saturday, August 23, 2003

Sometimes the inmates really are running the asylum.

http://www.cooper.com/content/insights/cooper_books.asp

UI Designer
Saturday, August 23, 2003

I can see this either way -
Pro-managment: in the 80's software engineers were demigods; you simply didn't "swap" them. Today the pendulum has swung to the opposite direction where management considers software developers completely fungible (the truth lies somewhere in between).
I can see management just being completely scared to fire anyone on the team, for fear they'd never get the product working again. What they *should* have done is fired the team lead and replaced him (be prepared for your entire team to walk out when you do this).

Pro-developers: like the other posts here - the engineers were right that the customers didn't know what they were asking for. It's up to the sales staff in this case to teach the customers what they really want. We do this all the time in my current company. Of course, another question would be - is it possible to "bend" the truth when dealing with the customers so they think they're happy, but they're getting a better product? (IOW, rename the feature)

Philo

Philo
Saturday, August 23, 2003

Perhaps the engineers have their points.  I mean, if
you ask Linus why can't the kernel be more like Windows,
he would flatly rejected the whole idea.

Amour Tan
Sunday, August 24, 2003

Linus *has* flatly rejected the idea of making the Linux kernel more like Windows (or any other non-monolithic traditional UNIX design). He had an infamous flame-war with Andy Tannenbaum over it about ten years ago.

Peter da Silva
Sunday, August 24, 2003

And I'm quite sure that Linus' technical decision, which has its pros and its cons, does not reflect on IBMs and RedHat's sales force.

A good salesman can sell a lesser product and make the customer believe he's getting more. A bad salesman is unable to sell a superior product, even though it's way better than the competition.

Product quality, especially in the computer business, has much less to do with it.

Ori Berger
Sunday, August 24, 2003

I couldn't agree more. A company hires salespeople to sell their product even if it's not the absolute best out there. Most of the time if the salesguys complain that they can't sell your product because it's not good enough (and existing customers aren't firing you), it's time to get new salesguys. Because the ones you have just don't know how to sell your product.

Rob VH
Monday, August 25, 2003

A couple of replies:

I did 5 years of support for VRTX sales calls and it was the 'features' or lack thereof and some poor QA that did VRTX in. Perhaps a better way to put it is lack of response to market demands. And that was directly traceable to the engineers in charge. I was there and I have pondered it for nearly 15 years since.

I saw many salespersons come and go, and even the best couldn't make a dent. In this case it wasn't the sales guys.

I should clarify that these weren't 'mere sw engineers'. They were very top level senior guys in a small company, so they had a lot of clout.

VRTX and PSOS were pretty equivalent in price and product line breadth.

david howard
Monday, August 25, 2003

I worked for a large consumer electronics company from 1990-1998.  We shipped on the order of 4-10 million units per year during that time, with the following OS's:  uTOS, Helios, pSOS, and later VxWorks (once WindRiver bought pSOS).  In my time there, I'd never heard of VRTX and don't recall a sales team ever coming to call and make their pitch.  I do remember the people at pSOS being relentless, to the point that we almost didn't buy their OS because they were so obnoxious.

But, their pricing was excellent, and it came with no strings attached (unlike many people selling OS's at the time, namely OS9, and later WinCE).

At least from one end-user's point of view, there was no marketing effort.

Pandora
Monday, August 25, 2003

In my experience the biggest threat to the software and therefore to the long term survival of a software company is adding too much to the software and making changes and additions at customers requests without thinking and planning it through very carefully.

What usually happens is that one the purity of the architecture has gone the quality of the code goes downhill very quickly and it rapidly becomes much harder and slower to fix and enhance.

Eventually the decision is made to either rewrite or refactor the software but by then it's too late. Refactoring can work but it probably takes months to do enough and few companies will let the development team spend several months just refactoring code putting all bug fixing and enhancements on hold.

And it also becomes impossible to ever write version 2 of the software because there are so many customer requested features that sales won't let development drop that it becomes financially impossible to justify the time and expense a new version will take.

I've seen more than one company lose it's main product this way - it has become too bloated to maintain and too expensive to rewrite so it continues along becoming slowly more buggy and more overtaken by rival software without all the bloat until it has to be scrapped.

By adding or changing features you might get 25% more sales (for example) but you are risking total collapse of the product in a few years.

Often the only people in the position to judge that risk are the developers as they *can* understand the sales position but to a salesman architectural purity seems like something only a geek would want because it's not something you can understand until you've worked on very large and old programs and seen what happens to them.

Maybe you should trust your developers to do their jobs and leave the salesmen to sell the product the company makes and not some other product that they with they made.

xyz
Monday, August 25, 2003

*  Recent Topics

*  Fog Creek Home