Slashdot Mirror
Why Software Sucks
Trent Lucier writes "Why Software Sucks professes to be a book for computer users, not programmers. Author David Platt wants to be the informant, pulling back the curtain on software development so mere mortals can get a glimpse inside the sausage factory. Platt flaunts his geek cred, all the while implying that he's not one of those geeks. But ultimately, trite observations and a condescending tone left me wishing that the book would end long before it did." Read the rest of Trent's review.
Why Software Sucks...And What You Can Do About It
author
David S. Platt
pages
272
publisher
Addison-Wesley Professional
rating
5/10
reviewer
Trent Lucier
ISBN
0321466756
summary
Explains to non-tech people why software quality is so bad.
The spectrum of what constitutes bad software is mostly limited to usability, security, and stability. No mention is made of supremely sucky software features like digital rights management, spyware from "reputable" companies, and bundled bloatware. There is plenty of information about these topics that the general public could benefit from, but none is to be found here. To his credit, Platt does mention annoyances like "free registration required" news sites and privacy issues.
The chapters focusing on software shortcomings all have a similar structure. The problem is put into historical context, a reason is posed about why the problem still exists, and readers are given advice on how to fix it. The insights into the world of software development are limited and stereotypical. In Platt's world, programmers are ego-driven, awkward geeks who only care about creating whiz-bang features at the expense of usability and usefulness. They're elitist and lazy, passing off responsibility to the user via confirmation dialogs and convoluted options menus. They go to tech conferences and pay more attention to the amazingly realistic software rendering of a bikini babe as opposed to talking to the real woman standing right next to them.
Of course, stereotypes are often true for a subset of any population. But Platt's characterizations are shrill and condescending, often reading like they were co-written by Comic Book Guy and Ann Coulter. Little mention is made of anyone else in the development process besides programmers. (Because, you know, in the history of the world, a marketing manager has never had a bad influence on a product. Nope, never happened).
Usability labs are cited as a great way to improve product quality. Great, but who is in charge of funding usability labs? Not programmers. Most programmers I know would love to have their product improved upon with usability testing. And by the way, if you think the previous sentence lacked supporting evidence, get used to it, because that's the level of research that is found (or not found) throughout Why Software Sucks.
The examples are typically shopworn (Yes, the Google homepage is simple and easy to use. We get it. Lord Jesus, we get it.) or trivial. UPS.com is constantly scorned throughout the book because it asks the user for their home country instead of detecting it via the user's IP address. Starbucks.com commits the deadly sin of defaulting to a 5-mile radius for it's store locater instead of just listing closest stores. Yes, these are annoying faults, but are they really the best cases out there?
Readers are given advice on how to improve software quality, and it all boils down to boycotting bad products, sending letters to companies, and spreading the word among friends. If you need more firepower, you're out of luck. How can I get my employer to use better software products? Or my local government? Can I leverage accessibility and usability laws in the fight against bad websites? Are those crickets I hear?
In the second half of the book, Platt takes a turn towards sociology and tries to explain the environments that geeks gravitate to. His prime example is the Microsoft Tech Ed conference, which, given the way he describes it, doesn't sound very different from any other kind of conference. Marketing bozos, gratuitous tschotchkes, after-hours drinking by the speakers...it could just as easily be the annual gathering of the Coffin Retailers of America.
Platt has mastered the art of the non sequitur. Theorizing that maybe the problem with software is that the field is too male dominated, we are told that, "Many people think that the recent child molestation and cover-up scandals in the Catholic church stem at least in part from the hierarchy's all-male culture." Gotta love those "many people" and what they think might "in part" be a cause of a problem. "Like Israel, Microsoft is finding out that being on top isn't quite as much fun as it looked like it would be when it was on the bottom." Does that make Apple the PLO? My favorite example is when Platt draws inspiration from How To Win Friends and Influence People. "Dale Carnegie lists rules #7 for making your home life happier as 'Read a good book on the sexual side of marriage'." I had to re-read the enclosing paragraph several times before I realized that Platt's advice was basically, "Read new books."
The biggest problem with the book is that it just feels lazy. Platt constantly references other authors that write better and have more insight into the topics he covers. Bruce Schneier. Vincent Flanders. Eric Sink. It's like watching a bad documentary about sci-fi movies, and constantly getting tortured with short clips from Star Wars, The Matrix, and Blade Runner. At a certain point, you just want to throw the damn thing down and go straight to the source material.
Sometimes, Platt saves you the time and quotes the source material wholesale, as in his section on Po Bronson's spoof "The Seven Habits of Highly Engineered People." Each entry is listed, and Platt explains it all to the reader. As I read this chapter, the introduction to Strauss's "Thus Spake Zarathustra" began to play in my mind. I slowly looked toward the sky as I realized that, yes, if this is what it takes, then maybe I, too, could write a book.
Platt invites readers to join his software quality movement and devise some type of "software seal of quality". The accompanying website, suckbusters.com, is clearly unfinished, so I cannot be too critical of it. However, it's hard for me to resist mentioning that a site about sucky software appears to be written in FrontPage and uses frames.
Is there anything in the book worth recommending? For a seasoned software developer, no. If you want a mature analysis of why software is hard to develop, read Brooks' The Mythical Man-Month or Demarco & Lister's Peopleware. If writing human-usable programs is hard for you, check out the writings of Steve Krug or Jakob Nielsen.
But what about non-technical users? Will they learn why software sucks? I keep trying to imagine someone having an intelligent discussion about bad software after reading this book. I can't. They will probably have the courage to say "software sucks". But these days, who needs to read a 272-page book to realize that?"
You can purchase Why Software Sucks...And What You Can Do About It from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
The spectrum of what constitutes bad software is mostly limited to usability, security, and stability. No mention is made of supremely sucky software features like digital rights management, spyware from "reputable" companies, and bundled bloatware. There is plenty of information about these topics that the general public could benefit from, but none is to be found here. To his credit, Platt does mention annoyances like "free registration required" news sites and privacy issues.
The chapters focusing on software shortcomings all have a similar structure. The problem is put into historical context, a reason is posed about why the problem still exists, and readers are given advice on how to fix it. The insights into the world of software development are limited and stereotypical. In Platt's world, programmers are ego-driven, awkward geeks who only care about creating whiz-bang features at the expense of usability and usefulness. They're elitist and lazy, passing off responsibility to the user via confirmation dialogs and convoluted options menus. They go to tech conferences and pay more attention to the amazingly realistic software rendering of a bikini babe as opposed to talking to the real woman standing right next to them.
Of course, stereotypes are often true for a subset of any population. But Platt's characterizations are shrill and condescending, often reading like they were co-written by Comic Book Guy and Ann Coulter. Little mention is made of anyone else in the development process besides programmers. (Because, you know, in the history of the world, a marketing manager has never had a bad influence on a product. Nope, never happened).
Usability labs are cited as a great way to improve product quality. Great, but who is in charge of funding usability labs? Not programmers. Most programmers I know would love to have their product improved upon with usability testing. And by the way, if you think the previous sentence lacked supporting evidence, get used to it, because that's the level of research that is found (or not found) throughout Why Software Sucks.
The examples are typically shopworn (Yes, the Google homepage is simple and easy to use. We get it. Lord Jesus, we get it.) or trivial. UPS.com is constantly scorned throughout the book because it asks the user for their home country instead of detecting it via the user's IP address. Starbucks.com commits the deadly sin of defaulting to a 5-mile radius for it's store locater instead of just listing closest stores. Yes, these are annoying faults, but are they really the best cases out there?
Readers are given advice on how to improve software quality, and it all boils down to boycotting bad products, sending letters to companies, and spreading the word among friends. If you need more firepower, you're out of luck. How can I get my employer to use better software products? Or my local government? Can I leverage accessibility and usability laws in the fight against bad websites? Are those crickets I hear?
In the second half of the book, Platt takes a turn towards sociology and tries to explain the environments that geeks gravitate to. His prime example is the Microsoft Tech Ed conference, which, given the way he describes it, doesn't sound very different from any other kind of conference. Marketing bozos, gratuitous tschotchkes, after-hours drinking by the speakers...it could just as easily be the annual gathering of the Coffin Retailers of America.
Platt has mastered the art of the non sequitur. Theorizing that maybe the problem with software is that the field is too male dominated, we are told that, "Many people think that the recent child molestation and cover-up scandals in the Catholic church stem at least in part from the hierarchy's all-male culture." Gotta love those "many people" and what they think might "in part" be a cause of a problem. "Like Israel, Microsoft is finding out that being on top isn't quite as much fun as it looked like it would be when it was on the bottom." Does that make Apple the PLO? My favorite example is when Platt draws inspiration from How To Win Friends and Influence People. "Dale Carnegie lists rules #7 for making your home life happier as 'Read a good book on the sexual side of marriage'." I had to re-read the enclosing paragraph several times before I realized that Platt's advice was basically, "Read new books."
The biggest problem with the book is that it just feels lazy. Platt constantly references other authors that write better and have more insight into the topics he covers. Bruce Schneier. Vincent Flanders. Eric Sink. It's like watching a bad documentary about sci-fi movies, and constantly getting tortured with short clips from Star Wars, The Matrix, and Blade Runner. At a certain point, you just want to throw the damn thing down and go straight to the source material.
Sometimes, Platt saves you the time and quotes the source material wholesale, as in his section on Po Bronson's spoof "The Seven Habits of Highly Engineered People." Each entry is listed, and Platt explains it all to the reader. As I read this chapter, the introduction to Strauss's "Thus Spake Zarathustra" began to play in my mind. I slowly looked toward the sky as I realized that, yes, if this is what it takes, then maybe I, too, could write a book.
Platt invites readers to join his software quality movement and devise some type of "software seal of quality". The accompanying website, suckbusters.com, is clearly unfinished, so I cannot be too critical of it. However, it's hard for me to resist mentioning that a site about sucky software appears to be written in FrontPage and uses frames.
Is there anything in the book worth recommending? For a seasoned software developer, no. If you want a mature analysis of why software is hard to develop, read Brooks' The Mythical Man-Month or Demarco & Lister's Peopleware. If writing human-usable programs is hard for you, check out the writings of Steve Krug or Jakob Nielsen.
But what about non-technical users? Will they learn why software sucks? I keep trying to imagine someone having an intelligent discussion about bad software after reading this book. I can't. They will probably have the courage to say "software sucks". But these days, who needs to read a 272-page book to realize that?"
You can purchase Why Software Sucks...And What You Can Do About It from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
I seem to remember thinking the exact same thing about Neil Stephenson's In the Beginning there was the Command Line. Pretentious and pessimistic. Thanks for the review.
Raging in an online forum won't do anything for the world around you. To see change, you must take action.
Did that guy ACTUALLY relate child-molestation cases in the Catholic church to poor software quality?!? Wow... just... Wow...
footballers shouldn't write books...
If software sucks so much, he should just stop using software all together... I'm sure he'll have a lot of fun using his computer without any of that evil software.
The review links to B & N, but I notice that Amazon has it cheaper (look under the "Used and New..." third-party sellers). One wonders why the editors keep linking to B & N if it's so comparatively expensive.
Actually, software blows! If you are finding that your software sucks, you just need to turn you computer around.
To summarize, they generally lack action and a good love interest.
It must have been something you assimilated. . . .
Terrible writing riddled with bitchyness.
I give it a 3/10.
No matter how neatly programmed or how much time people spend writing a program, truth is software is highly unreliable. There will always be something that will not work as expected no matter what software. Better acknowledge the fact. There is a difference between having a taste for programming and trying to make something work for everyone as they would want to.
The book sounds terrible, but I will agree that a large number of developers are blinded by egoism.
Spend a little time and you will find countless projects dividing talent among slightly different versions of the same thing and developers who really don't understand their users and don't want to understand them. "If they want something to be different, have them code it themselves!" is a tired refrain, but it points to a mentality of software for the developer, not the wider audience. While I'll admit that it can be good to mess around and create something primarily for yourself, when your goal is widespread adoption of your product, it certainly helps to consider what the end user wants to achieve, and what their standards for usability are.
Software development too often gets mired down in pissing contests, personal rivalries, egoism and Not Invented Here Syndrome and makes the developers appear amateurish and unreliable. This reflects poorly on their software, and we are left to hear them piss and moan about how their great app just can't make any headway against an entrenched rival.
Sometimes the competitor uses unethical tactics, sometimes users are just afraid/can't afford change. Other times however, the developer just wrote the software for themselves and never took the end market into account.
* BTW, Ann Coulter? Huh?
What I'm listening to now on Pandora...
Heh... the review makes a good point. The website for the book is incomplete and done in FrontPage 5. I'm serious when I say this... I'm gonna write him an e-mail and tell him how much his website sucks. Perhaps others should follow his advise and do the same.
Similes are like metaphors
Any ass monkey can right a book of criticisms... I would like to see his attempt at a software development methodology that is better.
Please sign petition to restore sanity to our banking system!!!
http://financialpetition.org/
Platt flaunts his geek cred, all the while implying that he's not one of those geeks.
Always sad to see a geek in denial. Embrace your geekdom, my brother! Revel in its glory!
"You will pay for your lack of vision..." - Emperor Palpatine to Ray Charles
Let's see, the gist of the review: "Nu-uh, we don't suck!"
Who writes the code? Who designs the software? SOFTWARE PROGRAMMERS!
(They don't get to be called engineers, because in order to be an engineer, there has to be a science behind the design instead of people randomly banging out code.)
Yes, software sucks because the people writing it suck. There is good software out there - it's hard to find and very expensive, but it's out there. Unfortunately since just about any monkey who can bang on a keyboard is allowed to program, there's also a lot of bad software out there.
It's not marketting's fault and it's not sales' fault that software sucks - they don't design it, they don't create the bugs, they don't create the features.
The only people who can possibly take the blame are the PROGRAMMERS.
Just like the reviewer blames the author of the book for the book sucking and not the publisher, the only people responsible for software quality are the monkeys that write it. Stop playing the blame game and accept responsibility for poor software already!
This is why I'm hiring the old fashioned monkeys with tails to write my software from now on. Need a job, AC?
As disgusting as it may sound, it actually is a very good description of what happens during many software projects. Of course, we shouldn't limit ourselves to just the Catholic Church as being an example of this problem. The Republican Party in the US is currently suffering from the very same problems, as shown by the recent Foley debacle involving inappropriate email messages being sent to teenage pages.
.NET (which of course does not run suitably well on Linux or Solaris, even when using Mono). After three months, and just before the first deliverable to the client, some of the mid-level managers found out that the implementation was completely unsuitable. Instead of dealing with the situation right away, they waited until after the customer rejected the first set of deliverables. Upper management got angry, but only shuffled (and did not fire or reprimand) the mid-level managers who knew of the problem but failed to act. The developers had to work extra hard to port their existing codebase over to Java.
The problem itself is one of a lack of responsibility. So you end up with programmers who make a mistake, and nothing is done to correct it by those programmers themselves. Soon the issue ends up in the hands of management, but not wanting to put forth the time and effort to get involved, they often ignore the problem. Soon after, the CEO and board becomes aware of the problems. Due to company politics, those middle managers who failed to deal with the problem early on are moved to different departments, or otherwise protected from taking responsibility for their misjudgements.
This is a situation I have witnessed myself. The firm was contracted to develop an application layer that ran on Windows, Linux, and Solaris systems. One of the managers made a mistake, and development starting using C# and
We need something like an installation controller. It would back up everything and monitor the installar and log every change to registry, disk, startup processes, changes to drivers, default handler assignments and everything. Then present to the user a simple standard user interface and allow the users to check and uncheck to allow and disallow changes. And all disallowed changes will be rolled back.
It would be initially confusing to many users. But the third party sites, help sites will slowly educate the users and eventually the people who hijack my resources will be black listed and go out of business.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
When we need a book to tell us that software sucks, that sucks.
Haven't read TFB yet, but I bet most of the software discussed in it is Windows-Only stuff.
It really comes down to:
1) Features
2) Cost
3) Time to market
4) Quality
Choose any THREE of the above.
Most software vendors do not compete on quality, they compete on one or more of the other three aspects. In SOME markets (telecom, avionics, etc.) - quality is more important. Releases tend to come less often and tend to be more expensive. Want quality software? Be willing to wait longer and / or pay more for it.
[Insert pithy quote here]
Software doesn't suck. It's great and has never been better than it is right now...well except for Microsoft software, anyway. Business, finance, transportation, communications, data management, entertainment, etc. are all incredibly enriched over what they were only 10 years ago because of...yes, software. The author is uninformed, misinformed or unexperienced or something.
What does that have to do with anything? That's not unusual. If you're a company looking for government to help you out, you would too. Republicans are all about corporatism.
Besides, I really doubt that the decision was made on a political basis, probably on who gives better referral commissions.
And say, since you brought it up, how do you know that, and what exactly is Barnes & Nobles's giving ratio?
he should have typed the entire book on a typewriter. bastard...
The reason software sucks is too simple. Software sucks because we don't care. But that doens't give enough material for a whole book I guess.
Really though, it is just that simple. We know how to make software that is reliable and secure. What do people buy? There is your answer.
And now to make sure I piss off everyone lets go beyond just slagging Microsoft since that is like kicking cripples. Macs suck too. Same for Linux, and BSD. All have bugs exposed on an almost daily basis. Why? Because nobody cared enough.
Ok, so what is my solution? Not giving a rats rectum about Windows or Mac limit my rant to Linux (and a bit of BSD). Start with OpenBSD as they are the closest to getting it right. Sure there isn't much in BSD, but what IS there is as reliable as an organization their size can make it. Features be damned, make it work!
So why couldn't organizations which have more resources take that idea to it's logical conclusion? Look people, adding new features before the old ones work is pointless and leads to software that sucks. Step one should be to take the Linux Standard Base and freeze it. Audit the crap out of it for security flaws and close every single bug report. Eliminate every compiler warning. Then look at every package that isn't at 1.0 status and decide what is needed to call it done and then DO it. Then begin moving that line outward. For now the graphical desktop environments probably can't be frozen, but everything underneath can be.
This won't happen though, because NOBODY CARES.
Democrat delenda est
software sucks because it's a very literal realization of a detail-oriented person's conceptulization of a process as related by at least one intermediate person (or, more likely, a committee of people).
If you take a programmer with no practical knowledge of the context in which the software is supposed to work, don't give them time to learn anything past the very basics, keep them at a distance from the people who will actually use the software, and have all the decisions on the functionality of the software, the timeline for delivery, and prioritization of the various parts of the software made by a committee of middle managers, marketing wonks, and executives you will get exactly the kind of sotware we all know and hate.
The best examples of software that I've seen were either written by a programmer with experience in a certain field working closely with an expert, or someone brilliant in a particular field who had a great idea and then picked up programming in order to implement their idea.
Insisting on "correct" English is like saying that there is only one, definitive recipe for chili.
It looks like you're trying to molest an altar boy. Would you like help?
- Get help with committing this sin.
- Just molest the boy without help.
[x] Don't show me this tip again.
See Sturgeon's Law
It applies to software and books...
You can't talk about Wikipedia's flaws on Wikipedia
If reviews were written only on books the reviewers liked, that would be one world of biased opinions don't you think?
Moreover, you seem to think that the reviewer is bashing the author/book where it appears to me like a good review and shows a lot of misses in the book itself. As an example, the author categorizes software developers in a very small box a bit too easily IMO.
Yes, I've read part of it, it is extremely short-sighted and won't help the supposed 'target audience' you talk about, in knowing more. Confuse them more? Definitely.
...regrettably out of print and, of course, now out of date... was Boris Beizer's The Frozen Keyboard: Living With Bad Software.
It is a classic, and well worth reading. And it does not condescend, and is full of good advice that naive users don't necessarily know. For example, don't type unreasonable values into fields... never enter data when the program appears to be busy doing something even if the program lets you do it... things like that.
"How to Do Nothing," kids activities, back in print!
A recent of example of why software almost sucks:
Software sucks because people get stuck in a mindset. Until last week, I thought that Thunderbird was easy to configure for email. Here is what I do:
- Enter incoming mail server name
- Enter login name and (optionally) the password
- Click ok
- Try to get your mail
- Now go back and try it with the SSL option
- Now go back and try it with the TLS option
- Now go back and try it with "Use Secure Authentication"
- Repeat combinations of the above until you find the most secure one that works
Recently, my wife got a Mac. Here's how to do it in "Mail" for the Mac:
- Enter incoming mail server name
- Enter login name and password
- Click ok
"Mail" connects, tries each possibility, and sets it to the most secure option that works.
Now until I saw this, I never even considered the possibility. Now, it seems quite obvious. Unfortunately, I have to ding them on this - if the password is wrong, it hides the error message from you (you get something generic like "connection failed"). So I spent two hours trying with the wrong password while damning Apple because I thought the problem was that their nifty "do it automatically" approach.
So let's review:
- Don't get stuck copying the way other things do it. Do it right.
- Make it easy by only asking the user for the things the user is responsible for.
- Don't hide information (such as settings or errors) from the user (yes, in "Mail" you can go back in and see what settings it picked)
If we could get the above three right, life would be much easier.
Save yourself $4 by buying the book here: Why Software Sucks. And if you use the "secret" A9.com discount, you can save an extra 1.57%!
Theorizing that maybe the problem with software is that the field is too male dominated
At this point I'd be praying that I get a paper cut and die from the resulting infection on the spot, rather than read any more BS from this guy!
Here's the problem with software, in a simple sentence: anybody can be a programmer, regardless of skill.
Think about it. What if medicine had no barrier to entry? Engineering? Accounting? You'd get the following:
1) very low fees (of course, it would be easy for ANYONE to undercut)
2) extremely poor median quality
3) mediocre or laughable skills in a large percentage of practitioners (dailywtf anyone?)
4) lowered expections from buyers (people would just come to accept that bridges often fall down, or 50% of minor surgeries end in death)
5) constant re-definition and re-invention of basic terminology and concepts that were nailed down years ago (wait! this is my POST-RELATIONAL OBJECT-ASPECT XML DATABASE! 2.0!)
6) articles and books decrying the lack of quality and coming up with nonsense reasons (but mommy, writing software is HARD! we can't expect programmers to do it!)
Any of that sound familiar?
That's because in the real world, linux is irrelevant.
Well, look-a-here, Hershel. We got us one of them self-hating geeks. Nothing I hate worse than a geek who doesn't appreciate his own rich heritage.
I think software is so complicated that testing every single scenario is way too time consuming, thus unreliability is inevitable. Also, software developer often get requirements and specifications that aren't complete, but are expected to continue on with development anyway. This introduces a lot of usability issues and bad design decisions. Bad software isn't a result of ego-maniac software developers, but organizational and process issues that result in bad decisions being made.
Of course then there are those bugs which comes from the oversight of the developers themselves. Hey, no one's perfect.
Brilliant. I guess since I don't play guitar, I can't say how much the band I saw last weekend sucked? Pffft. A genius you are not.
It doesn't mean much now, it's built for the future.
Everyone seems to be forgetting the real reason software sucks: all the developers are reading Slashdot instead of coding. Get back to work, you slackers!
I have seen the future, and it is inconvenient.
My experience with software development has been very, very different. Generally huge problems of communication between those who know the client needs (the sales staff mostly, but not exclusively) and the programmers were the biggest obstacle. The programmers didn't reject what they were told (out of egoism or what have you), but simply weren't given all the relevant details. They were then blamed when the software did exactly what they were told to make it do.
There were also problems of hard deadlines that were made without detailed estimates, and scope creep without deadline creep on top of that. These, too, were blamed on the programmers (they are so unproductive, they miss every deadline, etc.).
Basically programmers were given too much work with too little time and too little guidance, and then blamed for the shortcomings of the end result.
Of course...some of them were in that class of programmers who are only good at doing what they are told, and not good at being analysts as well. It takes a much higher level of mental versatility to be good both as a programmer and as a business analyst, which is precisely why such people cost more. If you want a cheap programmer, then don't expect him to perform like an analyst, and if you want an analyst who can program, don't expect him to be as cheap as a simple codebanger.
However...I did work at one place where a few of the programmers were supremely ego-driven. They got very upset when consultants were brought in to help with specific tasks that they had been stuck on for weeks, and also they were very quick to start badmouthing one another's code whenever anything broke. So I will not say that problems of software development are always the fault of the higher ups...but I will say that in my own experience the fault was usually with the higher ups.
I guess you could still blame the higher-ups for hiring programmers who were so egoistic...especially when more sociable ones were on the market...but that is tangential to my point.
Codebangers without the guidance of a good analyst won't perform well. Good analysts are expensive, so they are often skipped. The failure of the end result is therefore the fault of the ones who didn't hire an analyst, not the fault of the codebanger they did hire (for cheap) and expected too much from. That's my point.
>If you don't like a book, and you're not its target audience, then put it down and don't review it.
Actually, for once I'm glad to get a slashdot advert ( sorry, book review ) that is negative. I was getting fed up with blah blah this book is great blah blah followed by a link to buy it at an inflated price at BN.
Hey slashdot, how about a few bad reviews of software books? Or are you afraid to piss off your sponsers?
Open Source Drum Kit, LPLC deve board - mjhdesigns.com
....it's written by people.
May the Maths Be with you!
I write all my own software. I'll never give any of those lazy monkeys the opportunity to screw up my computer! As soon as I can get this hard-drivermajiggy to talk to that green circuity looking thing I'll be in business...
1. Fast
2. Cheap
3. Good.
Pick two.
Or just have a middleman who maintains a library of software packages that have been reviewed (in some cases, audited rather thoroughly) as being generally safe and what they appear to be, makes sure the packages work together, occasionally checks to see if updates and bugfixes are available, etc. The people must have expertise with the subject matter, have the users' interest at heart (!!), and have a reputation that can be lost if they screw up and be replacable (thereby being accountable).
We'll call that middleman a "distribution."
Think about it: when was the last time a Debian user typed "apt-get" and worried about an application also sneakily installing a driver or "hijacking resources"? When was the last time an OpenBSD user got a shitload of extra services installed that they didn't want?
Free software users have things so easy, because they already do have a "bill of rights" which they can enforce. It's a short and simple, too. Here it is:
Choosing to no longer be a victim has become one my most celebrated choices, an absolute no brainer in hindsight. People who haven't made that choice, have so many problems that are almost unimaginably alien to me.As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
If good software (often this is reduced to good UI design, which really ought to make the problem easier) were easy to write, don't you think somewhere during the past 50 or so years, someone would have figured it out and started a company to do it? And yet I have a hard time coming up with more than a half-dozen applications to which I'd give a score in the top 5-10% for satisfaction. No, I don't mean "more satisfying than 90% of software". I mean "90% satisfying". As in "less than 10% of things I try to do are harder than they should be".
So unless you've come up with a breakthrough in software or UI design (hint: you haven't), please stop killing trees to spread your words around. Thank you.
High-speed Road Trip (18.000KPH)
The child molester analogy is becoming common enough that it may supplant Godwin's Law.
Also, books don't fall out of the sky in final form. They are products developed at companies that wish to make a net profit from them in a fiercely competitive book market. The author of a book intended for the lay public is usually closely managed by the editor in charge of the project in order to insure that the target market is well-served. You need only watch a few hours of prime time TV to glean an idea of how to approach that market. To provide a book that passes muster with SW developers would be a blunder. To hype up pre-conceived stereotypes and stroke the lay reader would very likely prove useful. To drop famous names and quote from their writings, implying agreement with the book's theses, would also be a good idea.
They are trying to sell books, not philosophize at an intellectual café.
How can I get my employer to use better software products? Or my local government? Can I leverage accessibility and usability laws in the fight against bad websites? Are those crickets I hear?
To answer the first question, unless you're in the management or IT department of your company you CAN'T get them to use better software products. To answer your second question, you have NO BUSINESS telling your local government what software works for them. (And I'm an advocate of OpenOffice over MS Office for home use as well as using it at my job, but I work in IT) And to answer your third question, you can try, but you have no guarantee of succeeding, nor should you. You didn't pay to have the websites developed, therefore you have no say. In an ideal world people would just do the right thing. But this is far from an ideal world.
It seems to me that your rant (not really much of a review at all) is misplaced against this book. You're railing on about his attack on programmers but not paying attention to the fact that end-users and not coders are the target of this book. They could give a rat's ass about DRM because other than some minor inconveniences and some extra costs, DRM is transparent to them. We have a right to be angry about DRM because it hobbles programmers from being able to actually take advantage of whiz bang new possibilities afforded by upcoming technology since DRM imposes artificial restrictions on us. Joe Average will NEVER "get" that.
I agree with you in that he focused on the wrong stuff to a degree. He got it right as far as the average user goes. But if he was really going to show them the inside of the sausage factory (which I find disturbingly phallic mind you), he would point out that most people writing software today have no business writing it. All the slick IDEs that have been unleashed on would be coders and web developers has resulted in everyone and his brother being a "programmer". There are people developing applications and web sites out there who don't even know what structured programming or OOP are. They have no concept of the basics when it comes to writing code. Most of it is pieced together crap without reusable code even factoring in. It's beyond crufty. And THAT is why software sucks today.
-"...bad old ideas look confusingly fresh when they are packaged as technology" - Jaron Lanier (Digital Maoism on Edge.o
Trent just doesn't like how the catholics and jews were ridiculed. Trent is complacent enough when protestants are the target...
Seriously, that's basically it. It's perfectly possible to write software that doesn't suck- people do it all the time. (See pretty much anything written by JPL, for example)
But it costs. It costs for the good management&development team to decide exactly what the spec will be. It costs for good, experienced programmers to write solid, mantainable code. It costs for QA and UI people to go over everything with a fine tooth comb. It costs time to get it all right, and you're not going to get every wiz-bang feature because that would cost even more.
99.9% of users simply aren't willing to pay for that. The few that are live in niches where an accident is simply not acceptable. (See JPL, above, and even then they aren't perfect: see Spirit for an example) The rest of us settle for the likes of Windows and Office- lots of features, mostly works, ok UI simply because the perfect option would have a 1/10 the features and cost 10x as much.
"Seven Deadly Sins? I thought it was a to-do list!"
who thinks that the UPS and Starbucks "problems" have good use? Like the fact that UPS wouldn't always be able to get the correct home country for somebody using a remote proxy or that somebody might actually want to know all the Starbucks locations within 5 miles because that's as far as they're willing to go, but they might be in different parts of that circle at different parts of the day...? No, I'm not trying to make excuses for these guys, and I'm sure that it was really lazy programming, but that doesn't stop it from being useful.
Remember, open source is free as in speech, not free as in bear.
Yes because the Aryan race is known primarily for their high quality software. Like .. wait I can't think of anything.
So books are generated to make money. How then does that negate the need to review it? And the reviewer did try and think of how the target audience would benefit, or not from the book. His conclusion is that it was useless to them.
He is right with the four variables. Size, time, quality and cost are the four variables that (some people believe) can be tweaked in any project but since they all are connected and affect eachother, any change to one of the four will require changes in at least one more.
In practice however quality is not really negotiable and it should not be (that makes your point 3 invalid). And changing the required time is not easy. A project that takes two month with two people will maybe take only one month with four people. But it will not take only a week with 16 people. Customers usually have either a cost or a time limit and many times both.
The only real variable in a project and the one which makes the most impact is size or scope of a project. Usually customers can agree to substantial scope reductions when they see the price for the "required" features. At least this happened to me quite often.
Dan Brown ghost writes for Platt.
Javascript is required for simple hyperlinks to work. That's some quality suckiness right there. You really have to go out of your way to make a plain old hyperlink non-functional.
Edith Keeler Must Die
Oh dear, marked as flamebait. I guess our slashdot overlords can't take criticism.
Open Source Drum Kit, LPLC deve board - mjhdesigns.com
Software sucks because the costs of it sucking fall on the user, not the manufacturer. That's hasn't been true of automobiles for several decades now, and cars have gotten much better. When was the last time your car died on the road?
Many years ago, I was at Ford Aerospace when the Ford EEC-IV electronic engine control unit was being developed. In that unit, the program was permanent; it was in a mask-programmed device, and could not be changed without replacing the entire unit. Very substantial resources were devoted to insuring that there were no bugs that could cause cars to fail on the road. There was huge fear of a recall; if something had gone wrong, most of the Ford cars on the road would have to come back to a dealership for CPU replacement. There were old engineers at Ford who didn't want a computer to have direct control of the engine. Tweak the spark timing a bit or adjust the emissions valves, like the earlier models of engine control, perhaps. But actually fire the spark plug directly from software? That was radical. So everyone involved was paranoid about bugs.
It worked. Twenty years later, no bugs have been found. There was never an EEC-IV recall. The EEC-IV is still popular with enthusiasts. You can even download the code and run it in an emulator. I still have a 1985 Ford Bronco with its original EEC-IV, and it runs fine.
If Microsoft had to face the possibility of bringing every PC with Windows on it into an approved Microsoft repair center for a software update at Microsoft's expense, Windows would not crash. It might not do as much, but critical components of it wouldn't fail disasterously.
And that's why software sucks.
Some of the biggest flaws in Windows would remain flaws no matter how well they were implemented, because they're inherent in the high level design of major components, designs that were chosen for political reasons. bad user interfaces can be replaced. Bugs can be fixed. But there is no way to securely implement Active X as Internet Explorer uses it even if you got the ghost of Turing riding shotgun with Wirth and Knuth as pilot and copilot.
This isn't anything to do with software development. It's no different than the wrangling in the auto industry over seatbelts and air bags, or the oil industry pushing gas prices down on the run up to an election where an "energy-friendly" incumbent is in the white house.
I'd say Ann Coulter is way beyond being a simple neo-con, more like a neo-conehead.
Which pretty much means that all device drivers, almost any kind of firmware or assembly language code, OS code, networking code, etc., all suck -- by definition. Thanks for clearing that up.
I kinda figured that was true, 'cause when my computer blue screens and stuff I see a lot of hex numbers and weird crap like that and so that's probably machine language or something so that's why it probably sucked and died and stuff.
You can't use the keyboard to navigate to all the icons in a Windows application's toolbar? That sucks.
Your car stereo doesn't have a two-cent audio-in jack? That sucks.
Your cellphone's 'send to voicemail' button is right under your thumb when you flip the phone open? That sucks.
Your kids' school sends students home early when they don't have a class in the last period, but there's no school bus? That sucks.
Your TV reception is better than your cable reception, because there's an amplifier on your line that's flooded every time it rains? That sucks.
Your town built a bridge and created a stagnant pool right where the ouflow from the slaughterhouse hits the river? That sucks.
What makes anything think that bad design, screwed up decisions, and lousy implementation are unique to software?
A computer shall not harm the users' data, or through inaction allow that data to come to harm.
In most cases... yes. Cause most, or nearly all, builders are trying to satisify a large audience with a generalized solution. Like most professions, we have a scientific framework to express ideas & solutions, and evaluation of those ideas are [always] subjective. And guess what, most customers do not know what is common between them and all other customers using the same product that a builder is trying to serve. That's basic to any mass produced product. And since computer/software shortens the time span of pushing a product to market, you get less testing, less quality, increasing number of customer needs, and more dynamic and complex customer requirements. As a s/w developer, you have less time to develop and they, the customer, has more time to think about their individual needs.
Want 100% custom-tailored-to-you-bug-free software? Know exactly what you want and expect to pay dearly for it. Just think, it's no different than Ikea vs. hand crafted furniture.
Until software starts killing people by the thousands, it's "good enough" for now. It's like reading a Stephen King book. You just know it's going to devolve into something ridiculously stupid at some point. But you read it anyway, because it's "good enough" to help you get to sleep. People are used to disappointment. Programmers are just doing their part to maintain this universal truth.
Where did I negate the need to review it? Don't make up phantom claims.
And the reviewer did try and think of how the target audience would benefit, or not from the book.
He did not focus on the target audience, he mentioned it briefly as a secondary issue. He focused on a tangentially related audience.
He was the project leader of Internet Explorer 1 through 5, so if anyone knows about sucky software, he does.
It explained why Why Software Sucks sucks.
"No fear. No envy. No meanness." Liam Clancy
There are various theories here (in the book, review, comments) about why software sucks, but none of them seem to make more sense than Sturgeon's Revelation.
Being a developer myself, I'd like to argue that most developers aren't ego-driven and amateurish, but they are governed by Sturgeon's Revelation just same as most every other profession. This is certainly borne out by my experience anyway.
While academics were writing papers about formal proofs of correctness and such, businessmen were noticing that startups that quickly sent to market good demos with crappy to non-existant quality were drawing a boatload of investments and sometimes even producing big profits. The triumph of marketing over theoretical mathematics. It's not difficult to figure out which model most managers would want to copy.
It's not our fault!!... We do what are we told..., it's the functional analyst fault!!
The knowledge is something that you learn. The experience is something that you earn. The rest, you can buy it.
Uhhhh? What do you think the purpose of book reviews is? Or are you perhaps a publisher?
As I read this chapter, the introduction to Strauss's "Thus Spake Zarathustra" began to play in my mind. I slowly looked toward the sky as I realized that, yes, if this is what it takes, then maybe I, too, could write a book.
Do it! If your books end up even half as interesting as your book reviews, then you'll really have something. Good luck!
Mel Gibson? Is that you?
I know why software sucks. Its simple. If you have a physical product, and you make a mistake and need to fix it, it is very expensive to either get back all the broken products and fix them or to make replacements. Thus, you dedicate a lot of resources to make sure there aren't mistakes. With software, it is almost free to provide upgrades and patches. Thus, few resources are dedicated to quality control.
The masses are the crack whores of religion.
Lemme guess, his next book will be "Why Websites Suck"
w .suckbusters.com%2F
http://validator.w3.org/check?uri=http%3A%2F%2Fww
Developers do not need to know a thing about the subject mater they are developing. Software development is labor, and labor does not need to know why they are doing what they are doing, they only need to know how. The best software comes from small teams made up of good developers, good analysts, good architects and people knowledgeable about the subject. The software we have to day is built mostly by developer/architect/analyst (one person expected to fill all three roles) and sales reps (regurgitating unreasonable promises to they made to some client, internal or external).
Having worked as a developer, architect and project manager on Software projects in many diverse fields I can tell you from experience that the less your developers need to know about the subject the better the software will be. Because to have a team of developers that know nothing about the subject you actually have to write requirements and have reasonable test cases.
The problem here is that you have nothing to show for long periods of time and so most "clients" don't like the idea, but in the end you will have a much better product.
Oh and if you are curious I do support agile development and design just not agile planning and testing.
"Soft things sucks..." as my girfriend defines it...
---
and no, I do not need any Viagra...
...because the market tolerates it. As long as millions of people are clearly willing and eager to spend billions of dollars on software that sucks, why bother developing software that doesn't?
Downmodding is the refuge of the weak. Don't downmod, make a better argument!
Seriously.
There are a lot of subtle things that go into making a good user interface, and most programmers either aren't smart enough, or aren't aware of the problem, or don't care enough, to do them. And most of these things just require deep thought and hard work to get right.
That stupid-looking suckbusters.com sight appears to be a cause #1. I suspect that Pratt just isn't a particularly talented web programmer, and it shows in his site. I doubt if he has the ability to do better. Of course, if he were really aware of how hideous his site looks, he'd probably do something about it (or else maybe take it down), so maybe it's #2.
Have you read my blog lately?
As I read this chapter, the introduction to Strauss's "Thus Spake Zarathustra" began to play in my mind. I slowly looked toward the sky as I realized that, yes, if this is what it takes, then maybe I, too, could write a book.
'Thus Spake Zarathustra' was by Friedrich Nietzsche.
If you don't like a book, and you're not its target audience, then put it down and don't review it.
I found the review to be informative. I have to believe that the intended audience is programmers, no matter what the author says. Do you really think that non-programmers will buy such a book? Surely they are more interested in the latest novel, than in yet another vanity piece. The points that the book made needed to be addressed, and I thought that the reviewer did so.
It's a poorly written and misleading book; that's plain. The review saves those of us inclined to buy it from doing so. I doubt very much that the slashdot audience is composed of non-technical, mid-level managers. The review was intended for us, and it served the purpose.
The difference between a Miracle and a Fact is exactly the difference between a mermaid and a seal. (Mark Twain)
"They go to tech conferences and pay more attention to the amazingly realistic software rendering of a bikini babe as opposed to talking to the real woman standing right next to them."
Why not talk to that real woman? because:
A. You don't have a chance with a real woman.
B. You can't program real women to do 'stuff' (more like they program you in life).
C. The majority of women at a tech conference are paid to be there and have no interest in you.
D. She's married to some guy who looks 4 times uglier than you do, or so you think.
E. You can pimp out your CG bikini babe to all the other guys and make millions. You'll probably be paying for porn/sex even if you talkied with that real girl, so go for the money.
....1995 called. It says your website sucks!
And how many members of the non-technical lay public are going to buy a book that is about sucky software? Approximately 0 (within a margin of error of 1000). Nobody cares *why* software sucks, except software developers*. And nobody else needs to be convinced that software sucks - it's just not that controversial of a statement.
The only members of the public who might be tempted to even pick up such a book are those for whom the title is provocative and interesting - which is strongly correlated with those people who LOVE software and think it's all totally awesome, and therefore might be challenged and engaged by the contents. (See previous paragraph for an estimate of the size of this group, excluding software geeks). If you are not in this group, the subject falls into the same general category as "Why zits suck", "Why taxes suck", and "Why mean people suck" in terms of general interest.
* In this context, software developers includes anyone in the software business, not just programmers.
"home country instead of detecting it via the user's IP address." -- This isn't always accurate. What if user is behind a proxy, at school, at work, using someone else's Internet connection (e.g., wifi), etc.?
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
The comments sure are defensive around here, but I can't really figure out why. I live and breathe software development, and I'll be the first to agree: software does suck. It bogs the user down with unnecessary details too often instead of just staying out of their way. Simplicity is rare, most user interfaces are made to be flashy, and memory/disk space requirements are often ridiculous, given the scope of the application.
> UPS.com is constantly scorned throughout the book because it asks the user for their home country instead of detecting it via the user's IP address.
Wow, that's just weird. Personally I wish more websites (google, I'm looking at you) had this feature. And for a company like UPS... the author does realise that IP address based location is only approximate... doesn't he?
All these complaint about the book, and Alan Cooper's book essentially says the same thing. The inmates are running the asylum...amd posting on slashdot.
1) Microsoft.
2) Anti-Microsoft.
Microsoft has come up with bad user paradigms and then carefully polished them. Over and over, they fail to create a good program, and instead create a marginally usable one after the user has been trained to think like the program.
Then everyone else comes along and tries to write software which allows people to "break free of Microsoft;" but they do it by mimicking the software as closely as possible, because they forget that people are capable of learning something new. Once in a while, they come up with a new and different idea, but it usually sucks, because it's written by geeks for geeks.
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
Binary assembly code is an oxymoron.
Take that one step further, and we find that Debian has a Manifesto, a Constitution, a set of Debian Free Software Guidelines, and Debian Policy (which specifically limits what a package can, in specifies what it must, do). Combined with the packaging tools and conscientious developers and leadership, we get a distribution (and operating system) which says it puts the users first, and does.
There's reasons those of us who've used it for years, and really understand the technical and social process, truly love it.
"It's easy to tell a computer what to do. The hard part of programming is figuring out what the hell the computer should be doing."
My supervisor thinks it's easy to know what a computer should be doing. Then when it emerges that scores of little details have to be correctly linked, it drives him crazy.
Scott Adams is a Minor Deity.
My first Journal Entry ever, in 8 years! http://slashdot.org/journal/365947/aphelion-scifi-fantasy-horror-poetry-webzine
In the main, software is so fluid that the definition of "suck" changes constantly, and is always a moving target. Software will always "suck" because no matter how good it is, someone can always imagine something better -- and we know it can be written with just a little more work. I've been doing research into computing in 1987, on DOS machines, and today's computers don't suck -- ie they're easier to use and more powerful -- but today's programs "suck" because we can always picture the next generation DWIM interface that will replace them. If you gave a Linux box with Open Office etc to a DOS user in 1987, and somehow got them on the Internet, they wouldn't think the banal trivialities (who cares where a Starbucks is?) "sucked" at all. My TRS-80 Color Computer 2 probably "sucked" too but I never noticed it when I was learning how it worked!
If I write a book about how cars suck and that the people manufacturing cars in the factories should just make better cars because that is what people want. And then start waxing rhapsodic about how the public needs to come up with a standard for cars and put those damn manufacturers in their place.
I hope to that I get called on it.
Because the fault of shoddy software is not all from programmers, much like shoddy cars aren't the fault of the people actually building them. He sees a supposed problem (and ignores the wealth of great software out there, a lot which he probably didn't ever realize he was using) and then makes the mental leap that software has to be created by programmers at some level. They are the fundamental part of the chain. So it must be their fault. He ignores all of the other factors that contribute to software development and starts beating his chest at programmers like some goddamned ape.
Software does not drop out of the sky in its final form. They are products developed at companies wishing to make a net profit from them in a fiercely competitive software market.
And secondly, hyping up pre-conceived stereotypes and stroking a reader's ego does no one any favors. Not the audience or those the author is mocking.
Anyway, his review wasn't for people who agreed with the book, so you really shouldn't be commenting on it according to your logic. After all, you aren't the target audience, you couldn't possibly appreciate his arguements.
My twitter
Why Software Sucks Book Sucks
Everyone supported frames these days?
>Nobody cares *why* software sucks, except software developers*.
Perhaps this is exactly the problem
my password really is 'stinkypants'
If you don't believe me, ask the professionals. hates-software.com: the home of vitriol.
by not buying the book at all, thank you very much :-)
If that is what you want, check out Robert Slade's book reviews: http://victoria.tc.ca/int-grps/books/techrev/mnbk. htm
He hates all books! Well, almost all of them.
(1) Software is built by groups of people struggling with the unexpected.
(2) Software embodies values
(3) To be good, you have to be good at many things. To be bad you need just one.
The first point is that software is created by, in effect, committees. Committees are necessary to scale up performance in some dimensions, but they are notoriously inflexible and slow to adapt. How often do you look at a group of people trying to work together and think, "these people work really well together"?
The second point is that to get everybody working together, you have to instill some sense of what is important on the group. Is it being up to date with the latest technology? Is it design elegance? Is it selling like hotcakes? It it keeping support costs low? Visual attractiveness? While total failure out of the gate is not unheard of [note ironic use of understatement], I'd venture to say that most products that manage to get launched are wonderful -- until they get in the hands of users. The reason is a difference between what is valued by the developer and what is valued by the user.
The third point is that the team itself has competing interests. Sales wants a product with whiz-bang "curb appeal" and which sells itself; the programmers want a product chock full of interesting technologies they can put on their resume; management wants a product which will ship on time; support just wants something that won't make their life a living hell. How often is a project undermined because one concern was allowed to completely override the rest, or because people fought a turf war over priorities and everybody won?
Living with sucky software is like living with Original Sin: it's part of the human condition. The problem is us. We can't fix our software until we fix the organizations that build it; we can't fix the organizations until we fix the teams within the organizations. It would be very helpful if we could fix ourselves as individuals, but that is hardest of all; mostly we have to find ways of adapting teams to our shortcomings. Organizations need to choose the right individuals for new hires, and to educate those it has already hired.
The "UI Snob" viewpoint is just one viewpoint among many that claims the ultimate importance. Yes, its very important to get right, as is maintenance and support, project management, and profitability. The problem I think with the UI snob viewpoint is that it leads to fixation on venial UI sins while missing mortal ones. Yes, every application has a few UI blunders; an awkward dialog here, a mystifying icon there. In total, enough of these can make an application unusable. But this is not the source of application suckiness.
The biggest UI blunders aren't ones you can take a screenshot of, they are ones of fundamental logic where the application simply doesn't make what the user wants to do easy. The application may be impeccable on a micro scale. The real problem is that the organization doesn't value the same operations as the user. Technically this is a UI issue, but it doesn't fall exclusively within the realm of UI design. It is a cross functional organizational failure in which management, marketing and design all have a part. When a product is required to do more things, be shipped in less time, yet not create support issues, something has to be put on the back burner, and often thats the shmoe who has to use the thing.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
To provide a book that passes muster with SW developers would be a blunder.
Depends. You're right, if the only goal is to maximise the sales of the book. If you want to improve the quality of software, you're wrong, though. This book just got a "don't bother" review in a tech forum. So we computer geeks won't read it, and we won't know what (if any) useful suggestions he might have for us.
Of course, you could take this as an example of the problem that he's describing, in the publishing industry. Like most commercial software, the book was "managed" by people whose main (and perhaps only) motive is to maximise sales. Such managers have little interest in what happens after the sale, except insofar as it might affect subsequent sales. In particular, neither software nor publishing managers are concerned with writing software or books that appeal to their fields' "geeks". They want the product out the door by a fixed date, and they want whatever gimmicks will increase sales to the masses.
The result isn't all that difficult to understand. Especially if you've been involved in software and/or publishing, and seen firsthand the pressures that management puts on the authors.
Of course, here and there you do find good managers, and sometimes they can help a quality product sneak through the process.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
Business is business, and for its practitioners everything else is secondary.
You have to admit, it's a topic he knows a thing or two about.
Thats great, thanks!
Open Source Drum Kit, LPLC deve board - mjhdesigns.com
And if you conduct a search, you'll notice that Yahoo has adopted the colour scheme for its search results page of Google's search results page. I wondered if this was because they used Google's search technology, but the Wikipedia assures me that Yahoo uses its own crawler and database and has been doing so since their involvement in JFK's assasination.
"The use-mention distinction" is not "enforced here."