Fog Creek Software
Discussion Board




Why Software Is So Bad

http://www.technologyreview.com/articles/mann0702.asp?p=0

Poor management or lack of engineering dicipline?

apw
Tuesday, June 18, 2002

That would be "discipline".....

apw
Tuesday, June 18, 2002

Without having any quantitative evidence in front of me, I say that software is "bad" because customers are unwilling to wait for the time it takes to create good software and companies are unwilling to pay for that time anyway.  And usually (ignoring extreme cases given in the article), buggy software is good enough.

Crimson
Tuesday, June 18, 2002

“Software’s simply terrible today,” says Watts S. Humphrey, a fellow of Carnegie Mellon University’s Software Engineering Institute who has written several well-known books on software quality. “And it’s getting worse all the time.”

The quote seems to imply that once software was very good, and is now in a state of decline.

My memory must be failing me, but I have no recollection of that golden age.

Ged Byrne
Tuesday, June 18, 2002

Simply placing the cursor over the Visual Studio window, Downes has found, invisibly barrages the central processing unit with thousands of unnecessary messages, even though the program is not doing anything. “It’s cataclysmic….It’s total chaos,” he complains.

Isn't this like saying that opening our eyes barages our eyes with millions of photons even though we are not looking at anything?

Ged Byrne
Tuesday, June 18, 2002

"My memory must be failing me, but I have no recollection of that golden age. "

You're probably not old enough to remember. He's taking about the days when you'd be able to submit a compile job a day in the batch queue - and get the results a few hours later... Bench testing/code walkthroughs/etc all happened *before* doing hte first compile. None of this 'let me run the compiler to see where I made a spelling mistake.'

Jeff
Tuesday, June 18, 2002

Until the 1970s, compilers sat on large mainframes that were often booked days or weeks in advance. Not wanting errors to cause delay, coders—who in the early days tended to be trained as mathematicians or physicists—stayed late in their offices exhaustively checking their work. Writing software was much like writing scientific papers. Rigor, documentation and peer-review vetting were the custom.


What rubish.  Ken Brooke's Mythical Man Month was published in 1975 and described the same situation as today.

Ged Byrne
Tuesday, June 18, 2002

He states:
If the French coders had been drilled, like other engineers, in the history of their own discipline, the Ariane fiasco might have been avoided.

But before that:
And software engineering is a newer discipline than mechanical or electrical engineering; the first real programs were created only 50 years ago

Coders simply do not have the same history to draw upon that other engineers have.

The Voyage to Laputa, in Johnathon Swift's Gullivers Travellers, satirises the state of the art several centuries ago.  You may find the situations familiar.  For example:

There was a most ingenious Architect who had contrived a new Method for building Houses, by beginning at the Roof, and working downwards to the Foundation; which he justified to me by the like Practice of those two prudent Insects, the Bee and the Spider.

http://www.jaffebros.com/lee/gulliver/bk3/

Ged Byrne
Tuesday, June 18, 2002

The original design for Java?

The other, was a Scheme for entirely abolishing all Words whatsoever; and this was urged as a great Advantage in Point of Health as well as Brevity. For it is plain, that every Word we speak is in some Degree a Diminution of our Lungs by Corrosion, and consequently contributes to the shortning of our Lives. An Expedient was therefore offered, that since Words are only Names for Things, it would be more convenient for all Men to carry about them, such Things as were necessary to express the particular Business they are to discourse on. And this Invention would certainly have taken Place, to the great Ease as well as Health of the Subject, if the Women in conjunction with the Vulgar and Illiterate had not threatned to raise a Rebellion, unless they might be allowed the Liberty to speak with their Tongues, after the manner of their Ancestors; such constant irreconcilable Enemies to Science are the common People. However, many of the most Learned and Wise adhere to the New Scheme of expressing themselves by Things, which hath only this Inconvenience attending it, that if a Man's Business be very great, and of various kinds, he must be obliged in Proportion to carry a greater bundle of Things upon his Back, unless he can afford one or two strong Servants to attend him. I have often beheld two of those Sages almost sinking under the Weight of their Packs, like Pedlars among us; who, when they met in the Streets, would lay down their Loads, open their Sacks, and hold Conversation for an Hour together; then put up their Implements, help each other to resume their Burthens, and take their Leave.

But for short Conversations a Man may carry Implements in his Pockets and under his Arms, enough to supply him, and in his House he cannot be at a loss: Therefore the Room where Company meet who practise this Art, is full of all Things ready at Hand, requisite to furnish Matter for this kind of artificial Converse.

Another great Advantage proposed by this Invention, was that it would serve as a Universal Language to be understood in all civilized Nations, whose Goods and Utensils are generally of the same kind, or nearly resembling, so that their Uses might easily be comprehended. And thus Embassadors would be qualified to treat with foreign Princes or Ministers of State to whose Tongues they were utter Strangers.

http://www.jaffebros.com/lee/gulliver/bk3/chap3-5.html

Ged Byrne
Tuesday, June 18, 2002


It's simple:

Napolean: "No plan, no matter how perfect, survives initial contact with the enemy."

We have four things under our control:

    Features
    Money
    Time
    Quality


  If you demand many features, for little money, in little time, the only thing we can "cut" is quality.

  Like the song from rush "If you choose not to decide, you still have made a choice" (or was it Boston?) - Anyway, with customers screaming louder and louder, and smaller and smaller margins ...

  ... When the customer demands the impossible, they will end up buying from the guy who offers them the impossible.  And the results, though tragic, are sadly predictable. (Robert A. Heinlien)

Matt H.
Tuesday, June 18, 2002

I hate this generalization: software is not good or bad, software is software.

To say that software (which is a catagory) is bad is like saying that operating systems are bad. I like having an OS, though I don't know about anyone else here.

The software I make is not bad: what I have written so far I use regularly and by all availible accounts it is good. Most of the software I use regularly is of exceedingly high quality.

I find statements like "software == bad" to be incendiary and unnecessary.

Mike Swieton
Tuesday, June 18, 2002

I think the "mythical man month" was written by Ken's other brother Fred.

Concerning a quality aspect, software is bad.  It has been for about 30 years or more, ever since we started writing big complex systems.  Small, even one-shot programs, written by a single person will have higher quality than anything written by more than one person - unless, according to Fred Brooks, some means can be devised to maintain "conceptual integrity".

Writing software is not an engineering discipline, it is not like building a house, it is not something produced by a "factory".  It is closer to an art - an abstraction of reality.

Not one engineering discipline derived practice we have "tried" in the last 30 years has changed anything.  To insure that nothing is changed, we will continue to repeat that which has proved itself not to work, changing the name to pretend that it is something new and improved and guaranteed to work this time around. 

To date, the only significant accomplishments to advance our art has been assembler and structured programming.  All else is some extension/renaming exercise based upon these two primaries.

Joe AA.
Tuesday, June 18, 2002

About 2-3 decades ago the quality of American automobiles was rather low.  Compared to what?  Well, Japanese manufacturers started exporting smaller, higher quality cars.  It turned out there was a demand for them and the US manufacturers had to follow their lead.  I don't recall any significant general improvements due to lawsuits.

The quality of software could be improved if there was a demand for it.  We often hear of large differences in software quality and productivity between individual developers and companies.  But there doesn't seem to be much demand for the higher quality software.

It may be that customers don't what higher quality enough to pay for it (even if it's cheaper in the long run).  Or maybe they don't have any way to evaluate it.

mackinac
Tuesday, June 18, 2002


I'm going to paraphrase from mixed sources: :-)

"Companies want Wal-Mart Priced software.  What they often don't realize is that Wal-Mart Priced Software isn't a level worse than Target Priced Software - it's many, many levels worse than Target Priced Software.  Because when you go with the lowest bidder, you run the risk that the thing you buy isn't capable of doing what you bought it for.  And with software, that risk is much, much higher."

I think few people take this into account - they just want thier custom-build app to be cheap, like MS Word is cheap.  A Couplea Hundred bucks.  (They don't realize that Word Scales to 50,000,000 users * $100)  So they moan and whine to get project X in at $50,000.  When it should really cost $500,000.

So, they go for the impossible, complain about it, and the developers cut quality ... with sad but predictable results.

For someone with a better gift for word-smithing, see Tom DeMarco's take on this:

http://www.stsc.hill.af.mil/CrossTalk/1994/oct/xt94d10h.asp

regards,

Matt H.
Tuesday, June 18, 2002

The only permanent thing in our discipline is the software crisis. Since you quote Brooks or DeMarco over and over again, let me remind these two: "The end of computing science?" (EWD1304), and "Answers to students of computing science (the approximate reconstruction of the questions is left as an exercise to the reader)" (EWD1305).

http://www.cs.utexas.edu/users/EWD/ewd13xx/EWD1304.PDF
http://www.cs.utexas.edu/users/EWD/ewd13xx/EWD1305.PDF

Here's an excerpt:

I would like to posit that computing's central challenge, viz. "How not to make a mess of it", has NOT been met.

Andrzej Kocon
Tuesday, June 18, 2002

...and another one:

The required techniques of effective reasoning are pretty formal, but as long as programming is done by people that don't master them, the software crisis will remain with us and will be considered as incurable disease. And you know what incurable diseases do: they invite the quacks and charlatans in, who in this case take the form od Software Engineering Gurus.

Andrzej Kocon
Tuesday, June 18, 2002

As someone who depends on software to do my work, I've had ample opportunity to listen to product vendors explain why building large, bug-free software products is either prohibitively expensive or downright impossible. 

Inevitably, these explanations take me back to the days of Detroit auto supremacy in the 60's and early 70's, when car manufacturers pumped out products with numerous defects.  Customers routinely took their new cars back to the dealer a half dozen times to have one annoying problem after another fixed up.  Cars are complicated, we were told, and to expect perfection or anything close to it was unreasonable, and served as proof of the public's lack of sophistication in such matters.  Besides, car buyers would never be willing to put up extra cash for higher quality.  This argument worked as long as all of the automobile manufacturers bought into the idea that high quality was unattainable at a reasonable cost, or simply wasn't all that important. 

But Japanese auto manufacturers were blissfully unaware of the impossibility of manufacturing high-quality automobiles at a decent price.  Nor were they aware that prospective car buyers wouldn't value quality.  And because of their refusal to buy into the common widsom, they knocked American car companies for a loop.

It's easy to write off the Detroit experience as the consequence of staffing car companies with knuckleheads.  But while the American auto execs of those days may seem intellectually bankrupt in retrospect, they were extremely bright human beings with an awe-inspiring ability to rationalize their beliefs.  David Halberstam's "The Reckoning" makes this point about, oh, a hundred times. 

Which brings me to the state of today's software.  Programmers and software companies can continue to insist that bug-free software is an impossibility, as long as no one breaks ranks.  The software industry is blessed with a surplus of brilliant people who can out-rationalize any auto executive and keep the illusion afloat. (I live in Silicon Valley, the rationalization capital of the free world, where you can walk down any street and immediately find someone who can explain why you should buy stock in a company that will never make money, or why "Attack of the Clones" is a great movie.) 

But as soon as someone starts producing high-quality software that can be installed and maintained by a user who doesn't have a Comp Sci degree, many vendors of buggy software are going to be ground into dust, and we will have, in the vernacular of developers everywhere, a New Paradigm.  Don't think it can happen?  Ask the folks in Detroit.

Hardware Guy
Tuesday, June 18, 2002

"It turned out there was a demand for them and the US manufacturers had to follow their lead. I don't recall any significant general improvements due to lawsuits."

Really?  I guess _Unsafe at Any Speed_ doesn't count, huh?  Or the suits caused by the exploding Pintos and magic rolling-over SUVs.

Auto companies are scared to death of class action lawsuits now.  And vehicles are way safer for it.  Now, if only we could teach people to drive. . .

Acowymous Nonerd
Tuesday, June 18, 2002

Sure, most software sucks.  But let's not forget Sturgeon's Law:  "90% of everything is crap."

(Incidentally, the law is named after science-fiction writer Theodore Sturgeon, who was once asked why his favored genre typically contained such bad writing.  He allegedly replied, "Sure, 90% of science fiction is crap, but then again, 90% of EVERYTHING is crap.")  Or something like that.

Anonymous coward
Tuesday, June 18, 2002

No-one ever said that building bug-free large systems was impossible. We know it's possible, we even know the costs associated with it:

IBM run a team that writes software for the shuttle. They write as damn well close to bugfree code as you can expect. Seriously - cars are well made these days, Land Rover are amogst the worst producers of cars and still nearly 90% of them are OK. Nissan are amongst the best. Almost 100% work. They still don't have a zero failure rate.

IBM's team writes and maintains 420,000 lines of code. The last 11 versions of the software have contained 17 errors in 22 years. It takes 22 people to do, and $35 million a year.

So at a rough estimate, that's $700M gets you a bug-free .5Mloc. $1400 a line.

Now, I'm normally expected to produce at least 100 lines a day, and they're pay at best 50 quid an hour. That's looking worryingly like 5 quid a line and you wouldn't believe the noises people make when we quote those amounts at them.[1] What expression would the project manager have on his face if I told him he could actually HAVE the bug-free code he wants but it'll cost approximately 300 times as much?

On the bright side, that would probably stop people changing the strategic direction of the project every week. I bet the shuttle group don't have to put up with newly hired project managers turning up, randomly inviting themselves to meetings, halving their deadlines and mention "oh yeah, by the way this software will also have to be resold to this company over here that need to run an oil refinery with it..."


[1] Computer games developers, in particular, would be happy to hire us were we able to get the price under 1 quid a line. Wonder why Asheron's Call crashes a lot?

Katie Lucas
Tuesday, June 18, 2002

"Computer games developers, in particular, would be happy to hire us were we able to get the price under 1 quid a line. Wonder why Asheron's Call crashes a lot?"

It does?

b
Tuesday, June 18, 2002

Katie Lucas,

it's called incompetent management, full stop!
90% of projects fail, not because of technical issues, rather they fail because of political agendas/power plays that sets the tone for infighting and other such contrivances.

End result of which is poorly designed software, and compromises left, right, and center.

I'm certian that if you look that IBM Shuttle development team. More than likely they're organized using a concept/variation of peer management. [I.e. senior level very technical engineers doing what they do best, writing defect fee software, without the overhead of management antics]

cheers

Reginald H. Major
Tuesday, June 18, 2002

Software is buggy because the developers put way too many "features" in the packages. If the stuff did not crash in the first place I would not need auto save. Nor is there a need for auto spelling or adding bullets or numbered lists (hey you can't count) or auto outlining or dancing paper clips or apps that play tunes when they start or...... All of those "features" are childish and annoying. I want:

Stability
Speed
Robustness (i.e good exception handling that is                endcap buffers)

end user
Tuesday, June 18, 2002

IBM are given tens of millions of dollars to develop their software for a specific task on a single near perfect hardware spec which was developed with similiar funding.

In the real world a company is given a hundred thousand dollars to develop their software for multiple tasks on a large range of possible hardware specs with hundreds of possible software conflicts all developed with similar low funding.

You cannot compare apples with oranges. 

Jack lives over there -->
Tuesday, June 18, 2002

I read an article in Wired magazine about the group that writes the software for the space shuttle, and how it turns out the best possible software in the world.  The article said that they focus on the process of creating the software more than the software itself.

Joel would love them because they never rewrite anything.  Every line of code has pages of comments derived from code reviews and bug fixes, and adding new code is an Herculean task of fitting it into a codebase with twenty years of history.  Every time they discover a bug, they re-review the code to find all other instances of it, and then ask themselves how the bug got in, and how they have to change the process to avoid introducing it again.

Then they stick to their process.

In a nutshell, they have a disciplined, mature process for creating high-quality software that they respect, trust, and don't mess around with except to incrementally improve.  They have no romanticism about coding, software, or tech.  They just make near-perfect software.

Justin Johnson
Tuesday, June 18, 2002

Just to bring you up to speed and reality, the formal term is FEATURE CREEP.  And to most sane developers it's the kiss of death to be avoided at all costs. 

Try it sometime, mention it to one of your developer buddies.  [they will instantly go into battle mode]

[Software is buggy because the developers put way too many "features" in the packages]

Larry From Queens
Tuesday, June 18, 2002

Here is the URL for an article on the shuttle software development team.  This article says  it is a Lockheed Martin group, not IBM, and there are 260 people.  An interesting article.

http://www.fastcompany.com/online/06/writestuff.html

mackinac
Tuesday, June 18, 2002

mackinac,
That was a great link, excellent insight also

Larry From Queens
Wednesday, June 19, 2002

>>>Which brings me to the state of today's software. Programmers and software companies can continue to insist that bug-free software is an impossibility, as long as no one breaks ranks.<<<

As I understand it the Japanese success was not the result of a belief in their ability to make defect free cars.  Rather it was based on Deming's theory of quality improvement.  First you have a way to measure defects, then you find ways to improve your production process to reduce defects.

Similarly, while I find the possibility of bug-free software unlikely, better, even much better software is possible and not very difficult.

Having seen software development of various levels of quality, I think the biggest impediment to better software is lack of demand.  It spite of all the hand wringing about bad software, quality is seldom taken in to consideration in the purchasing decisions.

mackinac
Wednesday, June 19, 2002

With all due respect to Ged:

"The quote seems to imply that once software was very good, and is now in a state of decline"

That is so true! Hey -- I had to use a software called MathCad for my Physical Chemistry classes. Was that a piece of crap. Even though it ran on a modern Pentium III computer it was slower than the Maple V I used on my old DOS 3.3 machine. Furthermore the Windows MatCad crashed frequently. The MathCad had horrible exception handling too. In contrast the Maple V was quite solid, could solve more complex problems and produced a print out that was just as readable as the MathCad. Yet Maple V was 8 years older than the MathCad!
Similarly I have an ancient Word Processor called ChiWrite. It does math symbols and footnotes beautifully. True I cannot embed graphs in between the lines of text but, heh, it never crashed. In contrast the word processor with the dancing paper clip and it's atrocious tables and backspace font problems, crashes on a routine basis. Finally modern software is ill concieved and slooooow.

coding our way to decline
Wednesday, June 19, 2002

Correction,  it's actually  perceived modification cost.

During a typical development project, the desired features might change 200-300 times before FCS.{Perception among those running the program is it's just a few key strokes, make the changes}.  Verses the reality, which is{every modification introduces it's one intrinic cost/RISK}.

Not very many people are able to properly ascertain the true cost/RISK, during the development phases.  It's only after a few dates are missed{Or the project fails}, that someone thinks to hit the panic button.

Related analogy:  To change the design of a car mid-stream during/before it's production run, results in $100's of millions if not Billions, retooling costs.{Net result, the designed is locked in.}

If the percieved cost of mods to features of a software product were thought to be equally expensive, defect free software would suddenly be the norm.

Have fun, create military grade code.

[
Having seen software development of various levels of quality, I think the biggest impediment to better software is lack of demand. It spite of all the hand wringing about bad software, quality is seldom taken in to consideration in the purchasing decisions
]

Reginald Major
Wednesday, June 19, 2002

Hmm, just want to point out that the theory behind many agile practices is that enormous demand has reduced the cost of changing features mid-stream.  (New tools, methods, etc.)  Feature creep considered not harmful, as long as releases are made and schedules stay sane.

The Space Shuttle is nice... but how would their lives be if they programmed on Windows?  Consumers will never underclock their machines like NASA does.  Defective software springs from the unholy intersection of CS, business, and performance.

Why not look to companies like Blizzard instead?  At least before being 0wned by Vivendi, they made quality software.  That's a standard worth shooting for, where normal apps are concerned.

Sammy
Wednesday, June 19, 2002

The basic argument is flawed. It consists of pointing to normal characteristics of complex software that hasn't been subject to ultra-strict, ultra-expensive checking, then saying some of those characteristics are "bad."

The it argues that those responsible for the software are deficient and have done something wrong.

These types of attacks are always made by people who don't write software for a living. The best response is invite them to do so.

Hugh Wells
Wednesday, June 19, 2002

------------------------------------------------------------------------
The Space Shuttle is nice... but how would their lives be if they programmed on Windows? Consumers will never underclock their machines like NASA does. Defective software springs from the unholy intersection of CS, business, and performance.
----------------------------------------------------------------- Sammy

Lets not forget that the Space Shuttle did fail - tragically.  The cause was not software, but a fault with an O ring that had been identified by Engineers but ignored by management.

http://www.me.utexas.edu/~me179/topics/lessons/case4articles/case4article4.html#Thecommission's

The problems are not unique to Software, they are the same whenever a professions integrity is compromised.

Ged Byrne
Wednesday, June 19, 2002

"coding our way to decline",

I can remember some great DOS software myself.  I can't remember the dros, but it was there.

Ged Byrne
Wednesday, June 19, 2002

Have you tried Maple 8?

http://www.maple4students.com/

Ged Byrne
Wednesday, June 19, 2002

I think we should distance ourselves from what the media is saying, and think about what's going on.  Very slowly, consumers are caring about quality.  It's very natural, after the gold rush, to now want functioning programs. 

Isn't this what we've wanted?  Consumers to want quality?  And those of us who care and can write pretty bug-free programs have an advantage.

Now, part of me fears they really don't want quality, and it's just a random media blip.  Otherwise corps would be grabbing OpenBSD for security purposes which is FOR FREE, for God's sake.

pete erlich
Wednesday, June 19, 2002

Matt H - '....Napolean: "No plan, no matter how perfect, survives initial contact with the enemy."

We have four things under our control:

Features
Money
Time
Quality ....'

In an ideal world maybe. Increasingly, software companies have less and less control over these four aspects. (you made that point differently) Because the barriers to entry to the software market are so low, and competition high, then some kind of natural selection occurs.

The market selects for software companies that deliver features (in increasingly short timeframes) and whose defects are tolerable.

There seems to be a rash of these "All software is essentially useless" arguments lately. The article in question suggests the apalling state of the 'designs' of such software; then they make the bridge building/aerospace reference. As if Windows could have been originally designed for the internet, any more than bridges built a century ago could have been designed to land 747s.

The essential property of software is plasticity - our ability to change it rapidly and cheaply (by comparison with construction, aerospace, automechanics etc.). The relative ease with which it can accomodate drastic and unplanned for design changes is why it is so successful, not some side effect of the process.

Certainly there is a huge desire to get some kind of the sanity of other fields of engineering in software; all of the advances in computer science have been invested in ways of taking on board larger scale projects. In the course of half a century the scale of these projects has gone up several orders of magnitude. In six thousand years of human civilisation construction projects have gone up what 4 or 5 orders? They have had the time to get the testing, replication right. In software, delivering functionality has our hands full.

The idiosyncracies of software are probably because the industry is very customer focused and highly competitive. It also embodies this really horrible paradox - The customer is always right, yet they don't know what they want. There is the expectation that we can deliver features that they haven't asked for. Without knowing what those features are we can only guess. So there is no possibility of a blueprint level design.

Regulation won't help - customers are willing to tolerate niggles as long as the software delivers worthwhile utility. WHo is going to wait 18 months for the end of clinical trials of Windows XP service pack N?

Ditto for legislation - the only people who will benefit out of that are lawyers.

As for innovation, thats what we have already. Innovation delivers new features and utility, it is much different from the disciplines necessary to bring reliability (patience, discipline, thoroughness).

I guess everyone is a critic. But when you talk about software in a reliable/security context, utility and ease of use are often diametrically opposed to security and safety. Clients demanded information systems that could be set up with minimal knowledge and maintenance.

Richard
Wednesday, June 19, 2002

Hardware Guy - "... But as soon as someone starts producing high-quality software that can be installed and maintained by a user who doesn't have a Comp Sci degree, many vendors of buggy software are going to be ground into dust, and we will have, in the vernacular of developers everywhere, a New Paradigm. Don't think it can happen? Ask the folks in Detroit. ..."

Vehicles are functionally equivalent and replaceable. You can trade in your Civic for a Mercedes and improve your circumstances.

Doesn't work in software. Users don't want an equivalent Office Product or OS that improves their situation. They want their existing Microsoft Office to anticipate every possible eventuality out of the box. People don't replace their software for equivalents in the main, because consistency of operation and file format compatibility is such a huge deal.

About the only approaches that can come close are the Open Source efforts: replication of functionality is one of the things that OSS does well. But OSS falls down at the customer side of things - UI and ease of install etc.

Richard
Wednesday, June 19, 2002

Ya know, I'm actually not in the "software" business per se, instead the web application business (so I hope I'm not trespassing - most of this stuff applies to me too) but one thing I've noticed is:

As more and more tools come out to "write code more easily" people who set schedules translate that into "write code faster" (they largely believe the marketing of the solution). The problem with that (even though it may be true that they gain some footing with it) is that then they write a completely unrealistic schedule, argue with the developers about whether it can be accomplished or not, the developers bust their tails to get it out to a deadline that *someone* has promised a client and put a lot of PR into...

And the thing sucks.

*sigh*

One thing I've noticed (with my company in particular, but it seems to be a common problem) is that there's a stereotype of developers that they don't want to get the product out the door. That they want to perfect things and will amble along lazily until they get something right.

I'm sorry, not the developers I know. Most of the developers I know are SMART ENOUGH to figure out that if they don't release something THEY DON'T GET PAID!!!

And yes, maybe there are some who don't know that, but they are typically the ones who rely on WYSIWYGs and are 18 years old anyhow.

I'm not saying WYSIWYGS or code helpers or auto utilities are bad - not at all - but if you get people whose qualifications are only in those things...well then...you've got someone who doesn't know how to debug once integration is done. Someone who doesn't know how to troubleshoot when their mechanically inserted code doesn't work quite right. So they mark it as an unfixable defect, everyone buys into it, and it goes out buggy.

Sorry - rant over.

Bevin Valentine
Wednesday, June 19, 2002

Hey!!!  Good rant!

WYSIWYGS.  Yep, I call them point and click programmers.  I had one on a powerbuilder project many years back.  Could code up anything if I could translate it into point and click language for him.

Quality is not straight line linear.  More time does not equal more quality, and less time does not have to equal less quality.  It curves, and there is an optimum point.  Trouble is, it is difficult to figure out where specifics change the curve.

Joe AA.
Wednesday, June 19, 2002

That's true Joe - The challenge is in finding the optimum point on that curve. I think my biggest frustration with the whole deal is that the people in my organization who typically make that decision are the least qualified to do so.

But perhaps it's because I come from a company whose background isn't online stuff - it's a company whose background is in classroom/paper based stuff (oops, did I just let it slip that I come from a learning company?) So we're trying to migrate things using the model that worked *before* that transition. And it's a struggle at best.

The other thing that occurred to me as I was driving home for lunch was that the other thing that WYSIWYGs did to my industry was created the illusion that *anyone* can program a web application with ease. As the economy struggles and I look at job descriptions (just in case) they are looking for someone who can do it all, from advertising to project specs, to project management to the actual code (oh, and by the way, they want you to have a PHD and they'll pay you 35k). And then they wonder why they can't find anyone competent to do that - and they wonder why code is buggy - and they wonder why everything is mediocre at best.

Hrm.

So given those things, and given the fact that it comes off as "whiny developer" when one tries to change any of that within the organization through direct means...how does one show the organization that doing things right...hiring people who are qualified (or rather, firing ones that aren't and keeping ones that are) is the best move for the organization, and the one that will ultimately make or break their survival in the marketplace????

Has anyone ever had success with this???

Bevin Valentine
Wednesday, June 19, 2002


"how does one show the organization that doing things right...hiring people who are qualified (or rather, firing ones that aren't and keeping ones that are) is the best move for the organization, and the one that will ultimately make or break their survival in the marketplace????"

  I suggest "PeopleWare" by Tom DeMarco.  (I know, he's been plugged a LOT lately.)

  Basically, he made the common-sense appeal that you are making, and he did it articulately, 20 years ago.  Many people in our industry haven't bothered to read anything about how to actually make those decisions; many others know what they "Should" do, see the company status quo, shrug, and live with the consequences of a bad worldview.

  My suggestion:  DON'T WORK FOR ONE OF THOSE COMPANIES.  Go on intellectual strike and refuse to work for a company that makes bad decisions and blames developers for the consequences of those decisions. 

  My $0.02 review of peopleware:

http://www.csis.gvsu.edu/~heusserm/CS/CS641/PeopleWare.ppt

regards,

Matt H.
Wednesday, June 19, 2002

You know Matt - you've made a good point, and an intellectual strike wouldn't be bad but for the fact that we've got to put food on the table somehow (I have 3 kids and car payments, makes it harder to go live in a tent - which I would, if I were only single).

Isn't this why unions were formed at one point? (I know the downsides to unions, my ex-husband was in one of them)

Is that a drastic measure? And would that even work, given that companies can import cheap labor - or move to other countries?

Maybe I'm beating my head against a wall for no reason. It's really easy for me to see that profits would have to increase if a company could only get it *right*, but I suppose in order to do that I'd have to run my own company (which brings with it a plethora of associated risks).

How does one *find* a company that gets it in this era of job scarcity?

Bevin Valentine
Wednesday, June 19, 2002

>>>how does one show the organization that doing things right...hiring people who are qualified (or rather, firing ones that aren't and keeping ones that are) is the best move for the organization<<<

Discussions like this (how to improve one's work environment or find a good one) come up here often, but we seldom make much progress in finding a solution.  If we keep discussing it enough maybe we'll come up with something.  I have a few ideas, but that's a different enough topic that a new thread would be appropriate.

mackinac
Wednesday, June 19, 2002

How and why did it ever become politically incorrect to fire morons and incompetents?  I wish I knew.  For me it was sort of like an overnight change at the company I worked at for a long time.  Seems something changed during 1997, but I ain't got a clue.

Joe AA.
Wednesday, June 19, 2002

Was there a lawsuit or something in 96-97 that changed all of that??

I think in part (and I'm just theorizing here) a great deal of that is due to people making those decisions not understanding the nature of work done, and thus making really dumb decisions.

Some that I can name -

A software engineer is brilliant (if a little cranky) - he fixes a lot of other people's defects for them in the spirit of teamwork and getting a product out the door. When it's time for layoffs he goes, with the explanation that he had "too many defects in his code" (as witnessed by the bug reports that stated who fixed the defects).

A project manager is also a great guy, with a good head for business. He kills projects that are not strategic for the company, or would plain ol' lose the company money. When the layoffs happen he goes, with the explanation that he didn't have enough projects (meanwhile other project managers are blowing scope and budgets through the roof).

It seems that there's a general lack of understanding by the people doing the firing as to what is "good performance" and what is not.

Bevin Valentine
Wednesday, June 19, 2002

Oh and Mackinak - I'd love to see a thread of that sort :-)

Bevin Valentine
Wednesday, June 19, 2002

How does one *find* a company that gets it in this era of job scarcity?

1) Be willing to move.
2) look really hard.
3) Repeat.

  There are good companies out there.  One trick is to try to find the people who are actually doing the various "neat things" we talk about here - Xtreme Programming, Agile Development, CMM, etc.  Make your own version of the "Joel Test" and ask it during the interview process.

  I've come to believe that unless you can be really picky, software dev  is a choice of the lesser of evils.  Do you want to be given a great deal of freedom, but have to deal with co-workers who slack?  Or do you want specific direction from management - who may be experts - but can be overbearing?  Do you want to work 9-to-5 every single day, and risk shipping late b/c mgt hates overtime?  Or be expected to give your life to the company?

  In this lost and fallen work, no company is going to be perfect.  As a co-worker of mine once pointed out, your best bet is to save up a lot, pay off your mortgage early, get a book published, and then you can work for who you want when you want. :-)

  Another option is to go on your own - which, again, is a game of risk/reward.  The potential rewards are great, but the risk is much more than staying at home, slinging code.

  Another thought - rise to the top of the industry.  Get the MSCS at night.  Teach college courses in CS at night.  Perhaps get a book published.  Contribute to IEEE or ACM.  In 10 years, if you live in a metro area, you could have enough offers that you can pick-and-choose as well as make demands.

  Or not. YMMV.  I guess I'm just a bit more optimistic.

  As to what someone wrote about firing losers ... it's a false economy.  Anytime you fire anyone you expose yourself to -risk- of a lawsuit.  Of course, the -real- weight of keeping a loser around (wrong kind of inertia and a bottomless pit you throw salary into every month) is going to cost more than % chance lawsuit * Avg. expense lawsuit.

  Of course, some smart MBA-types have done the math and decided the risk/reward doesn't pay off, so I dunno.

regards,

Matt H.
Wednesday, June 19, 2002

Unfortunatly, unless you're Microsoft, Time-To-Market is probably the biggest pressure in software development.  The first one in with a product that "doesn't completly suck" generally ends up ruling the market.

Most intelligent companies/managers would prefer to release software with less bugs, for the simple reason that fixing bugs earlier costs less than fixing them later.

But if you miss that market window, then you have no market and no revenue and it all becomes moot.

DGH
Wednesday, June 19, 2002

In more cases than not, poor performers are retained not out of political correctness, but because firing people is difficult and unpleasant.  Most managers, particularly those who have risen from the technical ranks and are confrontation-averse,  prefer to wait, hoping that things will magically get better. 

I managed a design group for about a dozen years; if asked to list my shortcomings, a failure to move quickly on firing underperformers would be near the top of the list.

Hardware Guy
Wednesday, June 19, 2002

Hardware Guy said:

"In more cases than not, poor performers are retained not out of political correctness, but because firing people is difficult and unpleasant."

Not only that, but the consequences of firing someone (here in the US, at least) are sometimes painful. It's not unheard of for the company to be sued and forced to pay back wages and penalties, as well as hiring back the individual in question.

The firing process anymore has to start with comprehensive documentation of the shortcomings of the individual. You can't just say "He wasn't doing his job," you have to provide documentation of precisely what the job requirements are, exactly how he fell short of them, all of the direction you provided so that he could meet the job requirements, and so on.

If someone takes the bus to work and is habitually late, you can't just use the fact that she was habitually late as a reason to fire her; you have to use the appropriate bus schedules to document that she could have been on time .

The small company I work for has had four problem employees I've been aware of. One took us to court (and we almost didn't have sufficient documentation to win), two accepted their dismissal without incident, and the fourth probably would have taken us to court, but left abruptly while we were accumulating documentation to support the prospective firing.

Steve Wheeler
Wednesday, June 19, 2002

Wow - so litigation is a major reason - that actually makes a lot of sense - seems to drive much in our society right now.

Thanks to the person who wrote about interviewing the company with Joel's suggestions - that's actually a really cool idea - one I didn't think of. I was struggling with "how do you ask a company if they are "good"" - of course they are going to say they are.

I think the time to market thing is an interesting point. I'd like to see a study that says that definitively the scramble half-baked approach actually gets things to market more quickly (or not - not would actually be a heck of a lot more satisfying *laughing*)

It seems to me as if the approach is "but we'll lose sales to the people who undercut time/money". My answer to that would be - is BMW losing any sales to Hyundai? Yea, they might lose the bigger market, but long term, things might be better with that strategy. But then again, the Hyundai's of the world often stay in business too - so maybe it's something that's just frustrating if you're in it?

Bevin Valentine
Wednesday, June 19, 2002

I don't understand this fear of lawsuits over firing people.  Most states are "work at will" states, meaning that any employee can be fired at any time for any reason (with the notable exception of certain specific, prohibited reasons, like race, religious affiliation, etc.)

Anonymous coward
Thursday, June 20, 2002

Steve Wheeler, a small company with four "problem employees" is itself the problem. I have NEVER had to document the failure of an employee and nor would I.

Hugh Wells
Thursday, June 20, 2002

It sounds like they didn't like coming to work. Also that they were junior staff. And you guys run around documenting the "problems." Huh.

Hugh Wells
Thursday, June 20, 2002

You know - part of that litigious attitude seems to be that people feel that it's a right to work, not a priviledge. In fact, people right now feel that it's a right to own a SUV and live in a huge house and...blah blah blah and feel a definite sense of unfairness when they aren't in that position.

I think we've gotten into this weird attitude where people (and I'm going to show my bias here) particularly those who have gotten degrees, think that it gives them the right to receive a 50k/year salary and have forgotten that the word "earn" is in there because you do need to actually do something useful *for* it.

But maybe that's just my perspective ;OP

Bevin Valentine
Thursday, June 20, 2002

I think for a few years there, it was far easier to stop giving someone raises, let them find somewhere else, and then grouse about their work once they're gone.  All my managers in the last few years who've had people problems have done this.  So I agree with others on this thread who say that technical managers often choose to be ostriches.

The interesting thing is to see what happens now.  Economy-wise, the musical chairs game has stopped.  The overpaid, arrogant morons working with you now are not going to get a better offer from someone else.  These managers have to learn a new strategy.  Inaction makes them look dumb anyways, when everyone *knows* whose work wouldn't be worth the cost if the cost was "free"...

Mikayla
Thursday, June 20, 2002

Bevin - I think the reason some people my age (24) feel entitled is because A) young arrogant people always think they are invincible until they take that fall, and B) for their whole working life, there has been no fall, rarely any warnings or even suggestions for improvement.  So you have people who are humble about their ability and constantly trying to improve themselves and those who have stopped.  Until someone rewards the first group over the second, only those of us who can and will do it for the love of it are going to belong.

Mikayla
Thursday, June 20, 2002

But you know Mikayla - that doesn't always seem to be the case. Often the people who get to stay are the ones who *look* like they are producing the most. Maybe it's just a PR game we all need to learn to play. I'll be the first to admit that personal ethics frequently get in my way of playing that game.

Bevin Valentine
Thursday, June 20, 2002

You're right - it's frustrating to me because I'm in that age group too (I'm 26 - so maybe I'm just over that hump).

Maybe it's due to the way they are being raised - Dunno - I started working at 14 (you can in Scotland). Grew up understanding the value of money and that no one gives you things for free...even respect beyond that of being an entity on this planet.

Even my own brother doesn't get it - so maybe that's not the case *shrug*

Thanks for the insights. Now if we could just get managers to let those people trip up enough to figure it out.

Bevin Valentine
Thursday, June 20, 2002

Bevin V, to find a good company, just find one that's run by a programmer.

Also, regarding your situation with pushy project managers, I was architect on a big project a few years ago where we had the same problem. And this is what I did.

Instead of running around like lemmings to satisfy the PM's idea of work, I did the opposite. I made everyone stop working late and stop working on weekends. I put a hold on coding while we quietly documented the requirements and made good plans. I told the guys that if the billion dollar company couldn't hire enough programmers to meet deadlines, or set the deadlines properly, that was the big company's problem, not theirs. We all relaxed after that.

The PM and senior management were getting frantic by this stage, but couldn't do much about it. When we started coding, we coded straight through. We met the deadline and our product was far superior to all previous efforts. After this, the PM and senior management formally adopted the techniques I introduced.

Hugh Wells
Thursday, June 20, 2002

Phew Hugh - you're gutsy :o)

That's also a very good solution. I think part of our problem is that we're all scared due to the 4 layoff situation (no one wants to rock the boat lest they be labeled and be the next to go!!!)

The projects with PMs who have a technical background go wonderfully - because they get it and are willing to fight the battles necessary with Upper Management to make it work.

The ones without it? Well those PMs want to see something *now* otherwise they don't believe that work is being done. It's a "we've got to see and show progress". Unfortunately code doesn't always work that way :-)

Bevin Valentine
Thursday, June 20, 2002

>Instead of running around like lemmings
>to satisfy the PM's idea of work, I did the
>opposite. I made everyone stop working
>late and stop working on weekends. I
>put a hold on coding while we quietly
>documented the requirements and made
>good plans.

For a business explanation of this scheme, see Steve MaGuire's book "Debugging the Development Process."  Steve suggested that we do this on every flailing project.

Has anyone here read "The One Minute Methodology"?  Supposedly, it talks a good deal about the difference between being a show-horse and a work-horse.  Sadly, you're right, the Show-horses tend to win.



regards,

Matt H.
Thursday, June 20, 2002

> Has anyone here read "The One Minute Methodology"? Supposedly, it talks a good deal about the difference between being a show-horse and a work-horse.

I've read it. Do not buy it: it's a "joke" book, not funny, takes 15 minutes to read.

Christopher Wells
Thursday, June 20, 2002

I might have know it had something to do with lawsuits.  The last person I fired was right around 1994 - he had survived in the company, changing jobs whenever his incompetence became too apparent.  Unfortunately for him, his last stop was me and no one else would have him.

And yes, it was quite a documentation exercise.  HR took the perspective that it wasn't his fault.  One rep blamed it on me because I wasn't about to give him detailed instructions on how to do his job.  I think that was something that really bothered me at the time... as a programmer, it WAS his job to think.  Someone taking dictation from me on what he needed to code wasn't doing me nor the company any good.

Part of the change I noticed not only included *cough* a greater tolerance for someone like the above individual but an actual tendency to promote them through the ranks faster.  One explanation offered to me was that they were actually *cough, cough* higher level and more sensitive individuals - as if it were not necessary for them to learn the basics of the job.  One was promoted to where her job consisted of no greater duty outside of what you would expect from an "admin assistant", but given the pay of a senior programmer.

I hate the word "entitlement", but that was what it smelled of...  Eventually, the productive left.  It was really too bad, prior to that it was a great place to work.

Joe AA.
Thursday, June 20, 2002

It sounds like Joe AA was seeing the Dilbert Principle in action:  "The most ineffective workers are systematically moved to the place where they can do the least damage -- management."  The idea is that they suck at their current job, so they'd better be moved to a position where they at least won't cause six-month development delays.

My Dad dealt with an individual like the one Joe describes; this coworker would only do exactly what he was told to do, down to the *letter*, and never anything more.  It was infuriating.  But, since this was the federal government, nobody was willing to fire him.

:sigh:  So it goes.

Brent P. Newhall
Thursday, June 20, 2002

    I don't understand this fear of lawsuits over firing
    people. Most states are "work at will" states,
    meaning that any employee can be fired at any
    time for any reason (with the notable exception
    of certain specific, prohibited reasons, like race,
    religious affiliation, etc.)

          Anonymous coward
          Thursday, June 20, 2002

I'm in a right to work state. However, if you don't have proper documentation, it's your word against theirs as to why the firing occurred. Also, keep in mind that it's not just wrongful termination lawsuits that are possible; it's also the possibility of lawsuits related to unemployment compensation and other things.

    Steve Wheeler, a small company with four
    "problem employees" is itself the problem. I
    have NEVER had to document the failure of an
    employee and nor would I.

          Hugh Wells
          Thursday, June 20, 2002

The four problem employees were not all at the same time, or I'd probably agree with you. This is over the past 16+ years, in a company that normally has 10-12 employees at a time. I'd say the average time our current employees have with the company is about 7 or so years, and that includes two who only have about 1 year with the company.

    It sounds like they didn't like coming to work.
    Also that they were junior staff. And you guys
    run around documenting the "problems." Huh.

          Hugh Wells
          Thursday, June 20, 2002

Nice that you've got a handle on our shortcomings. Obviously, you've discerned that I'm part of the evil and clueless management cabal.

Actually, Hugh, this is a fairly nice place to work. I've been here over 16 years, and someone else besides the owner has been here longer than that. Every company has a corporate culture, and some people will fit in with it better than others. See me over a beer sometime and maybe I'll tell you stories to curl your hair, but don't presume that I'm a fool or an asshole before you know enough (and you didn't in this case).

Steve Wheeler
Thursday, June 20, 2002

Joe AA - "...How and why did it ever become politically incorrect to fire morons and incompetents? I wish I knew. For me it was sort of like an overnight change at the company I worked at for a long time. Seems something changed during 1997, but I ain't got a clue.  ..."

I think around 1997 saw the beginnings of the very visible aspects of the tech boom. There was a lot of money going around to cash in on this new economy stuff. When before that development was the preserve of the reasonably competent, the whole new technology aspect levelled a lot of the skillset playing fields and a lot of charlatans and money grabbers could sneak in under the confusion, armed with a learn Java/ASP/Marketing in 24 minutes book and a subscription to wired.

If they didn't get fired in their first year, they could leave and w00t! they had one years experience in the new IT industry. They would get found out if they tried much programming, but they new enough talk to climb into superiour positions.

There was so much turnover of staff for the next few years and so many mangled products, that incompetence was very easy to disguise. But nobody was really searching for it, they were too busy seeing 100% annual growth in their stock options ...

Richard
Friday, June 21, 2002

Bevin: "... Wow - so litigation is a major reason - that actually makes a lot of sense - seems to drive much in our society right now. ... "

Consider that it is much easier to fire someone in the US. In Europe labour laws are much stricter. I can only recall maybe one incident where someone I knew was fired. It was a manager and the reason was justified, but even then she was given the opportunity to fall on her sword so to speak, and notice pay.

Generally, employers tend to have probationary periods of up to 6 months. Failure to perform up to scratch tends to have employment not renewed, or the probationary period extended. The latest round of redundancies gave a lot of local employers the opportunity to remove people they didn't like.

The biggest thing is how loosely removal of employees can be applied. Another poster commented on the visibility of someones work. As the kind of person who tends to take on the unglamourous but necessary work, this is something I am very acutely aware of. It has happened to me before that nobody recognised my achievements and it hurt my career (wasn't removed though).

Some people can get very difficult work that requires a lot of support from the organisation. If they don't receive it, it could be shown that they could not perform adequately. Some people get highly visible projects like making new GUIs which are easy and high profile.

" ... I think the time to market thing is an interesting point. I'd like to see a study that says that definitively the scramble half-baked approach actually gets things to market more quickly (or not - not would actually be a heck of a lot more satisfying *laughing*) ... "

With stuff like JSP/ASP you can deliver visible functionality in extremely fast cycles. This has seduced an awful lot of managers around where I live. The code produced by this can barely survive another iteration. Them teams either rewite this expensively or are doomed to ahve flakey software. Very few can actually overcome this obstacle, I am trying to see if my company can ...

" ... It seems to me as if the approach is "but we'll lose sales to the people who undercut time/money". My answer to that would be - is BMW losing any sales to Hyundai? Yea, they might lose the bigger market, but long term, things might be better with that strategy. But then again, the Hyundai's of the world often stay in business too - so maybe it's something that's just frustrating if you're in it? ... "

Richard
Friday, June 21, 2002

" ... You know - part of that litigious attitude seems to be that people feel that it's a right to work, not a priviledge. ..."

I don't know about that. I mean sure there are people out there who thinks the world owes them a favour; but I have found very few of them that are core IT developers. Where I come from, graduating from a software course at degree level is hard. Or well it was anyway, before they started expanding their curriculums with much more industry friendly stuff (I learned Java on my own in college, now its replacing C++). Dropout levels were nearly as high as 50% of course entrants. Anyone who survives that has some degree of competence.

Most of the achievements in free societies over the last 100/200 years have been towards improving the lot of the citizenry. Social welfare, trade union movements, civil rights, healthcare and improving prosperity. Employment as a privilege doesn't wash. it implies that an employee should ingratiate themselves to their employer, as their presence there is a favour offered them by their employer.

That approach works well in sweatshops where the most complicated thing being made are toys and track shoes. Employees there show their gratitude by working cheaply and not taking toilet or food breaks during 12 hour shifts.

knowledge workers work best when they are unstressed. Employers know this too, it applies to all professionals and this stuff is taught during management courses anyway.

In a free society everyone should have the opportunity to participate. Employment is the means by which most people do this.

I have rarely seen much in the form of incompetence from my peers. I have seen a lot more in management levels. Where staff empathy, leadership and understanding of the nature of their productivity have been sidelined in favour uninformed planning meetings, office politics and ordering people about.

There have been examples of people lying on their CV, especially contracted staff, a lot of pseudo developers who graduated in arts/business via MCSE (but even those people are useful in supervised/junior roles).

Then again, one of the core roles of management is to get the best from your staff. I wouldn't put junior/less skilled people in charge of important projects, but if you do, and they fail, is that the employees fault or the managers. In this industry, knowing the difficulty of a task is a skill in itself - junior people rarely have it.

I just think that a lot of litiguous attitudes by employers stem from some desire to have employees perform at their best without any employer buy in or investment in the employee.

Richard
Friday, June 21, 2002

"I just think that a lot of litiguous attitudes by employers stem from some desire to have employees perform at their best without any employer buy in or investment in the employee."

Employment is by contract, not obligation of the part of either employee or employer.  Employers have a right to expect the employee hold up his end of the agreement by performing to the best of his ability.

Discussions of employees around the "water fountain" usually show a different assumption, that the employer has the obligation to "make them happy" and they are entitled to it through some mystic reason not in the implied contract.

And there are employers that do exploit their employees, also for reasons not in the implied contract.

I wouldn't consider the socalism aspects of history as "achievements".

Stress?  Ok... how come every frustrated worker regards their frustration as something that someone or something else does to them, and ignores the "strain" aspect, meaning their reaction to the stress?

Joe AA.
Friday, June 21, 2002

Joe AA
"...  Employment is by contract, not obligation of the part of either employee or employer. Employers have a right to expect the employee hold up his end of the agreement by performing to the best of his ability. ... "

I am not disagreeing with that, but employment as a privilige implies obligation on the employees part that is not specified in the spirit or letter of the contract.

" ... I wouldn't consider the socalism aspects of history as "achievements". ... "

How so? Workers rights, minimum levels of pay, child labour laws, emancipation of women, maximum working hours, how are these not achievements? These aspects have enriched our lives. By allowing us to concentrate less on mere survival we are able to concentrate more on academic pursuits, medicine, the arts, technology, sport and other human achievements that can be ploughed back into the economy anyway.

The employers didn't see their share of the pie disappear through increased costs, the entire pie grew. I think thats a pretty good achievement. A long way to go yet, though.

"... Stress? Ok... how come every frustrated worker regards their frustration as something that someone or something else does to them, and ignores the "strain" aspect, meaning their reaction to the stress?  ..."

Blowing off steam is my way of dealing with stress. Some people take it differently. 10 minutes later I am back at work. YMMV. That or the prozac in the watercooler ....

Richard
Friday, June 21, 2002

Hmm... drugs in the watercooler... now that could have some real possibilities!!

The socialism doctrine that makes it Ok to rob me because I do productive work to give to those that refuse to do productive work... well, I can't see it as an achievement.  Chalk it up to my limitation.

I don't know how it is in your country... maybe employment as a privilige means something else, or maybe I just don't get what you are trying to say - it seems like we are saying the same thing.

Here... the workers have the true power.  They also choose not to exercise it, and in many cases, refuse to admit it even to themselves.  It's called "voting with your feet".

Joe AA.
Friday, June 21, 2002

<OffTopicRemarks>

Richard,

I have to disagree with you about the socialism.  Political interference of any stripe in economics, or more generally in the right of private contract is always wasteful.  It's true that mankind's situation has vastly improved over time by any number of measures.  You attributing this to interference in the marketplace is unfounded, however.  What is amazing is that these things have been achieved *in spite of* all the interference and manipulation. 

It's fairly easy to demonstrate, logically or empirically, that so-called social benefits like workers' rights, minimum wages, and the like only prevent people in general from enjoying richer lives than they already do.  I don't want to clog this discussion with another long, off-topic post, however, so I'll end here.  Feel free to send email (or start another thread if no one objects), if anyone would like to spare the group, but continue the discussion.

<OffTopicRemarks/>

Keep_Your_Rules_To_Yourself
Friday, June 21, 2002

Off-topic:

Prozac is over-rated.  See:

http://www.thomasjmoore.com/pages/prozpop.html

Sarah Tonin
Friday, June 21, 2002

Software can be bad in two ways:  its stability and its UI.

For example, I do most of my programming in Microsoft Access with Access VBA.  (Whether or not you think it is a "real programming" language is for some other debate).  The point I want to make is this:  VBA has (1) rules, (2) quirks and (3) missing features.  To wit:  We have to deal with the annoyance that recordsets that are not explicitly closed will crash Access even though they are out of scope.

To even use a File Open dialog box, I must use APIs.  When I read that not being careful about the values you pass in API function parameters could cause Windows to crash, I began laughing.  That's crazy!  The function should protect itself from garbage.

Programmers like to program.  They want to "get this project going" by churning out reams of (what ends up as) poorly written, hard to read code.  Creating table relation diagrams don't look as though you are doing anything.  Managers must screen shots. 

As for user interface design, it's a relatively new field, but what strikes me as odd as the many programmers have unrealistic expectations from users to remember things. 

Think about the American soldiers that were killed in Afghanistan when they called a missile strike on themselves.  In fact, it appears a soldier programmed the coordinates to strike in the GPS unit, then changed the batteries, not realizing the GPS unit resets itself to its own coordinates when the batteries are removed.  If anything, the GPS unit should:

(1) remember the user's last settings, or
(2) set itself to NULL, or
(3) confirm that you want to drop bombs on yourself.

When people are shooting at you, don't expect the user to remember things a computer could.  This mistake is clearly the fault of the designers and programmers of the GPS unit.  It shocks me that no one at the design meeting thought, "Hmm, if a soldier can call a strike on any valid coordinates, what happens if he inputs his own location?..."

What do you end up with?  Programs that crash alot and corrupt data, people get killed and VCRs flash 12:00 all over the world.  My bet is that Access and alot of other products are programmed by caffeinated twenty-year olds will little regard future maintenance.  Trying to get my colleagues to adhere to just a coding style and to use a consistent naming convention is like herding house cats.  Also, if I could any one thing it would be to ban all goto type instructions in all procedural type languages.

My conclusion: Software is bad because it takes years to be able to program in a particular language well and not enough thought goes into design.  Everything's done in a hurry and it shows.

Gary
Monday, June 24, 2002

I agree that everything having to be done in a hurry is the main reason for poor software. The planning stage is the most important part of a good program. You need some sort of WRITTEN flowchart or pseudocode. You also need a client that knows what they are doing, knows what they want and is able to WRITE it down. You need to write comments in your program so you know and others know what you are doing.

In fact, what I do in my programs is write a few paragraphs of comments which include what the client wants and exactly how I plan on doing what the client wants.
I've found 2 or 3 hours  spent doing this saves roughly 2 or 3 months of time; no exaggeration.

Most babies, many bosses and many clients need everything NOW. Babies are the smarter, more mature, and least annoying of the three.

Don't let some screaming idiot or your own impatience make you skip the planning stage.

Jim
Thursday, April 01, 2004

It's klear that many of the authors are deficient in speeling yet they persist in waxing philosopically. No wonder the compiler becomes the kulprit.

Judge Knot
Monday, April 05, 2004

*  Recent Topics

*  Fog Creek Home