> At my last place of employment, a large project that could
> not be utilized for legal reasons was pushed into
> production so that the project could be declared a
> success. All it was doing was burning CPU cycles for
> quite a while.

Did you grab that out of Dilbert? It seems too ridiculous to be real. It really shouldn't surprise me.

> In some of the places I worked, managers' compensation
> (raises + bonuses) were related to annual goals such as
> getting XYZ project into production by a specified date.
> The managers naturally urged the software along before it
> was ready.

I like to call these artificial constraints. It all stems from the need to make quarterly and annual reports. Pulling "successes" into the current period results in (short term) stock increases. Pushing "losses" into future periods avoids (short term) stock decreases. This pattern is firmly ingrained in corporate culture. I think there is also a tendency to lump all the "bad news" into one period, because the cumulative effect of one big beating is smaller than several smaller ones.

So the entire corporation is incentivized to deliver positive results new and let negative ones accumulate.

The fundamental problem is despite billions of dollars of research and really, really smart people working at it, people haven't become that much better at predicting future events than astrologers. So decision makers focus on what they know is true now.

> > At my last place of employment, a large project that
> could
> > not be utilized for legal reasons was pushed into
> > production so that the project could be declared a
> > success. All it was doing was burning CPU cycles for
> > quite a while.
>
> Did you grab that out of Dilbert? It seems too ridiculous
> to be real. It really shouldn't surprise me.

Burning CPU cycles seems like a rather minor consequence. I've seen thousands of well paid professionals sit idle because groups decided to push software out way before they could possibly conclude that it works. I've seen manufacturing facilities essentially shut down for weeks.

> Burning CPU cycles seems like a rather minor consequence.
> I've seen thousands of well paid professionals sit idle
> e because groups decided to push software out way before
> they could possibly conclude that it works. I've seen
> manufacturing facilities essentially shut down for weeks.

The worst I've seen is software being pushed in that managers admitted would only meet 40% of the users' needs because "we've invested too much to throw it away".

Now that I think about it, I heard a similar manufacturing story. A complete soup-to-nuts business package from a large, not-to-be-named-here software company was pushed in and the facility couldn't input orders for over two weeks.

I always find myself looking for problems and thinking "What could go wrong?" and "What would break this code?", so I tend to spend more time on this than on the rest. But edge conditions are important, so I feel it pays off.

If people are failing to use intefaces correctly, it may be carelessness, e.g. not reading the documentation carefully - but I've seen plenty of poorly specified interfaces that are counter-intuitive or complicated to use. A much neglected problem is poor naming - names enable us to visualise how an API works, and what a class, method, or variable does, and poor naming can seriously impair understanding of code.

This seems like the thread where I think to myself, "if I ever run a company, I now know of more folks for my mental list of people I would want to recruit for it." Sort of a self-selecting population, here.