The whole time I feel like smacking the design guy in the face and saying "why don't YOU fuckin' code it?"
Some of the worst code I have ever seen is produced by places that have 'architects' that sit around and pontificate rather than working directly on projects.
I think that's inevitable. Taking your best programmers and keeping them away from the code is idiotic. In the short term, you're cutting the them off from all of the little details that the need to know what the right design is. And in the long run, you make sure their skills are stale and atrophied. And as a bonus, you imply that the rest of your programmers are drones, mere assembly-line workers. That's great for morale.
More than once I have told a client that the best possible thing they could to is take all their architects and make sure they spend at least half their time coding with the teams they advise. And the next best thing would be to take away their power to issue mandates, so that they have to act like a resource to the people doing the real work, rather than just being a bloviating bureaucratic burden.
While it may be true that designing is the most critical part of coding, it's dangerous to equate the code and the design. Because that implies, obviously, that writing code is the same as designing it, so just skip any forethought about design concerns and launch right into the coding.
Sweet Jesus! Did you even read the articles linked? For example, this part?
Nevertheless, people keep insisting that my contention of "the source code is the design" means "don't do design, just code." I never said anything of the sort.
If you're going to misunderstand the guy, you could at least do it in a new and interesting way.
I will admit to being a project manager, not a developer.
Ah, so that's why you feel qualified to give opinions on something you didn't even take the time to do the reading on.
But there's no substitute for writing the requirements, feature definitions, scopes and dependencies first, then the comments in the code blocks, then the code, and tar'ing those docs with the source code. The initial hump is steeper, but the total area under the work curve, over the product lifecycle, is much less.
I'd agree that if you're doing waterfall, doing design docs is better than not doing design docs. But I disagree that there's no subsitute.
Having done a few Extreme Programming projects, I much prefer that. Between continuous design, unit testing, acceptance testing, refactoring, and pair programming, I think you get much better code for less money. On a recent project, for example, a 36 developer-month effort released in October and has had a total of two bugs in production and zero downtime.
And the code is in great shape. If a potential investor wanted to send in their technical team for a review, I'd have no fear. Heck, I'm more confident than that: if another team were taking over the code base, I'd happily give them my cell phone number.
If you subsume the design into the implementation, then someone who goes looking at the implementation will have no way to distinguish between what was a design decision from what should be relatively arbitrary implementation decisions.
Well, that's only if one doesn't write tests and writes muddy code. If I want to know what a bit of code is supposed to do, I look at the method name, the class name, variable names, and the unit tests for the class. If those are good, then I don't need a spec. And if those are bad, generally the spec is useless anyhow.
But if I'd have to pick just one thing to be right, it would be the unit tests. Everything else, I have to check by hand. But the computer can check the unit tests for me.
I'd go a step further and throw a semantic error if suffeciant comment's were not found before certain constructs. Hell, make them part of the language.
Please don't make me kill you.
One of my least favorite things to do when taking on a new code base is to spend hours and hours deleting all the useless comments: the obsolete ones, the redundant ones, the misleading ones, the ones that are completely obvious, and the many, many comments automatically inserted by an IDE.
And people already do this even when the language doesn't require any comments at all. Of the last three code bases I've picked up, about 90% of the comments were worse than useless. I can't imagine what the ratio would be like if a fussbudget compiler required you to put in "// asdf asdf asdf" before every new method and every block.
People who are bad at explaining a precise algorithm's details in an elegant form using Java, C, Perl, or Python are also bad at explaining it in an elegant form using English, for the exact same reasons. They're just not good at communicating carefully and clearly in general.
Agreed! The solution to bad programmers putting out confusing structures in code isn't to get them to produce a parallel structure of documentation.
So selling a product at a profit isn't a real business? What would they have to do to count as a real business?
Real businesses are those that provide fair value for money spent. Real businesses are ones where if the customers had all pertinent information and plenty of time to think about things, they'd still do the deal.
How is selling something taking advantage of the customers?
I believe what the poster was objecting to was the many bullshit tactics that printer companies currently use to take advantage of customers. E.g., using the DMCA to prevent competitors from making reasonably priced cartridges that work with their printers.
The difference between Us and John Gilmore? We're not millionaires who think bureaucracy should be spat upon at every step.
I've met John Gilmore on a few occasions over the years, and I have never seen him act in an arrogant or overbearing fashion. He's always been mild, polite, and friendly. It wasn't until the third or fourth occasion that somebody mentioned who he was, and until then I had no idea; nothing about the way he acts conveys that he happens to be rich.
So unless you have some more evidence than his bank balance, maybe you can lay off the unfounded personal accusations.
Much better is an explanation over a block of 5-10 lines giving you an idea of what you are trying to achieve. Comment any thing that is not clear, like if your using bitwise shifts to multiply and divide, for example.
I used to write lots of explanations. I still do when I have to, but now it feels like a defeat to me.
Instead, I try to make the code readable enough that it doesn't need explanations. E.g., I'll take each of those 5-10 line blocks and do an Extract Method refactoring. The information that would have ended up in the comment ends up in the method name, in the parameter names, and in the return variable name.
Also, I put a lot of that energy into writing good unit tests. Comments can get out of date, but unit tests always tell the truth.
Find a vendor you think will be good, have them break the project down into chunks of no more than a couple of weeks each. Have them do the first chunk only, with the understanding that if they do a good job, they'll get more work.
Then make sure the first chunk is done completely and well before giving them the next chunk. Accept no excuses or promises that they'll make you happy down the road. Do not give them the final payment until things are 100% complete. An incremental approach will substantially reduce risk of project failure.
Also, I strongly recommend that you pick somebody who writes unit tests and acceptance tests for their code. Having automated tests makes it much easier for other developers (yours, theirs, or new vendors) to work on the project.
Here is an idea, why dont you just fucking google it.
Here's a question I didn't find such a good answer to in Google: Was it really necessary to be such a prick?
If you would have read past the first question mark in the guy's post, he isn't just asking for the name of one place that's selling them. He's also asking when or even whether these systems will become common. For somebody who's about to drop tens of thousands of dollars, those seem like pretty good questions.
Funny, Google isn't coming up with such good answers on that. Boy, if only he could find a community of people who make their living on the cutting edge of technology. Maybe some of them would know! Perhaps you can share the Google query that will help him find somewhere like that?
I deal with project managers from the oil, gas and chemical fields every day and these guys and gals are well trained at what they do. [...] Now, with respect to software, from what I have seen anecdotally there's just not the same kind of rigor placed on most software projects, even large, very expensive software projects. The upfront definition tends to lack the type of detail you see in other (physical) capital projects. [...]
This is a topic of hot debate in the world of software development. For many years, people have assumed that software development was like any other construction project, and that if you just applied more project management practices from those domains, software development would be better. This has not been broadly successful.
In the last five years or so, a set of approaches collectively known as Agile have arisen. They all recognize that unlike buildings or bridges, which include a moderate amount of design and a large amount of expensive, hard-to-change construction, software development is different. Software is mainly a design activity; we have automated most of the construction phase (via things like compilers). Software is, in a word, soft.
Agile methods take advantage of this difference, favoring continuous planning rather than trying to do all the planning up front.
So my advice to the original poster is to carefully study the agile methods like Extreme Programming or Scrum to see what you can learn from them. I've tried projects both ways, and I heavily favor the agile methods over the heavyweight ones.
This is a good start, but there are a couple of ways to improve.
First, Java's serialization format is pretty opaque. That makes debugging, testing, and schema migration a pain in the ass. A better choice is XML via XStream. If you have a good object model, its output XML is pretty readable. And you can improve that by adding custom adapters for particular objects. And for the XML-is-too-verbose crowd, let me suggest putting a GZIPOutputStream in the chain.
You generally do have something like GameMap or MobileObjectsHashTable though.
This is a good approach in Perl, but in Java you can do better. When I see classes with names like that, it generally means the programmer is thinking too much about implementation and not enough about design. Instead of GameMap, it should be Game. Instead of passing in string keys and casting objects when you (hopefully) get the right ones out, take advantage of the language's static typing and put all that work inside of the Game object.
My question is : WHO CARES ? I mean, what the hell, why would I want to know how many people were involved in the fabrication of my fridge ?
I care.
I care about the people who have contributed to the open source projects I use because they have given me a fabulous gift, because they're doing something good for the world. They rule.
I only wish more of them lived in my neighborhood, so I could buy 'em a beer. Any of you open-source developers who live near San Francisco's Zeitgeist, drop me a line and I'll pour you a glass of Racer 5.
When they *started* doing Longhorn, it might have made sense to build three parallel development teams and pick the winner after two years. But now, adding people would likely make things worse.
Irresponsible PC users cause a lot of the major security issues in this connected world; you can't put all the blame on Microsoft.
I can sure try.
Microsoft is allegedly selling an operating system for average consumers and nontechnical people. Much of their target audience knows absolutely nothing about computer security and will do nothing to maintain their boxes. If they produce a product that the vast majority of their chosen market is known to be incapable of using responsibly, they should take the blame for that.
If it were utterly impossible to solve the problem technically, then maybe I'd forgive Microsoft and say that the government should require a license to own and operate a network-connected computer, along the lines of a driver's license and car inspection, or perhaps more like a building permit. But I think the problem can be solved entirely in software once Microsoft fixes some internal wetware issues.
So you think. It's all the rage now to have technial meetings where nobody speaks and all arguments are made through pantomime. I'm sure that's what he's talking about.
My favorite thing to explain that way is an elevator algorithm, although stochastic fair queueing is a close second.
Piling tons of extra work upon your programmers, and unrealistic deadlines, comes back to bite you in the ass in various forms.
Agreed! Bad (or just naive) managers focus on features and dates because those are easy to measure, and ignore reliability, productivity, and sustainability. That leads to the common phenomenon of having to do major rewrites every few years. This isn't inevitable; it's just the accumulation of a million tiny errors and mistakes. It's like tearing down and rebuilding your house every few years because you're in too much of a hurry to clean and maintain it.
My favorite thing about Extreme Programming is that it rigs the game so that managers can only adjust features and dates, not quality. And thanks to weekly iterations and a tight team environment, whenever anybody slacks off on quality, everybody feels the pain soon.
Remeber that you want your ISP to clamp down on illigal activity when you're trying to get a torrent of DVD rip or a newly release album on mp3.
If you read my post more carefully, I think you'll see that I'm not talking about what's illegal; I'm talking about what's bad for the neighborhood.
From a landlord's perspective, the problem with a crackhouse isn't that somebody's doing illegal drugs. If landlords kicked out every tennant who had ever smoked a joint, there'd be a lot of empty apartment buildings out there. The problem with a crackhouse is that it's an uncontrolled menace to the building and the neighborhood.
I don't much care whether the law formally recognizes the harm that spammers cause to the internet. (Sure, it would be nice, but our legislators' calendars are already pretty full doing the bidding of their campaign contributors; I doubt they'll have time for something that matters to mere citizens.) But I do care that network operators maintain an orderly network, and that includes cracking down on infected servers, hax0r kiddies, spammers, and other people or programs that abuse the network for fun and/or profit.
Additionally, I view credit cards as a fundamentally bad idea, because they make it very convenient and easy to spend money you obviously cannot afford to spend, because you don't have it.
This is a point with which I completely agree but is entirely irrelevant to the discussion.
Although I have no credit cards and never have, I can happily use the credit card network. How? I have a charge card, an American Express card: you must pay it in full every month. I also have a debit card, where the money comes directly from a checking account (in which I keep limited funds to reduce risk).
It does bother me that so many OSS projects use Paypal and/or credit cards as their primary system for receiving donations. [...] At minimum, they should accept personal checks.
You're missing the open-source spirit here. Telling a bunch of people what they should do is what you do with people who work for you, like the people you buy stuff from. In the open-source ethic, if you think the world should be different, you step up and change it.
The reason that most on-line entities don't take checks is that they're a pain in the ass to deal with and not many people want to use them. If you'd like to change that, then set up a service for OSS projects where you receive the checks and handle the hassle and then send them the money via PayPal or wire transfer.
All companies today use the following order 1. shareholders 2. shareholders 3. shareholders 4. company executives.
And your source for this information would be what exactly? I'm pretty impressed that you've managed to find out what all companies today do; there are a lot of them. Some companies that I know from the inside seem to have a different attitude, but I guess I must be mistaken.
J&J was in a shear panic over that incident.
A shear panic? Is that where you're so freaked out that you run with scissors?
Slashdot Mirror
The whole time I feel like smacking the design guy in the face and saying "why don't YOU fuckin' code it?"
Some of the worst code I have ever seen is produced by places that have 'architects' that sit around and pontificate rather than working directly on projects.
I think that's inevitable. Taking your best programmers and keeping them away from the code is idiotic. In the short term, you're cutting the them off from all of the little details that the need to know what the right design is. And in the long run, you make sure their skills are stale and atrophied. And as a bonus, you imply that the rest of your programmers are drones, mere assembly-line workers. That's great for morale.
More than once I have told a client that the best possible thing they could to is take all their architects and make sure they spend at least half their time coding with the teams they advise. And the next best thing would be to take away their power to issue mandates, so that they have to act like a resource to the people doing the real work, rather than just being a bloviating bureaucratic burden.
Sweet Jesus! Did you even read the articles linked? For example, this part?
If you're going to misunderstand the guy, you could at least do it in a new and interesting way.
I will admit to being a project manager, not a developer.
Ah, so that's why you feel qualified to give opinions on something you didn't even take the time to do the reading on.
But there's no substitute for writing the requirements, feature definitions, scopes and dependencies first, then the comments in the code blocks, then the code, and tar'ing those docs with the source code. The initial hump is steeper, but the total area under the work curve, over the product lifecycle, is much less.
I'd agree that if you're doing waterfall, doing design docs is better than not doing design docs. But I disagree that there's no subsitute.
Having done a few Extreme Programming projects, I much prefer that. Between continuous design, unit testing, acceptance testing, refactoring, and pair programming, I think you get much better code for less money. On a recent project, for example, a 36 developer-month effort released in October and has had a total of two bugs in production and zero downtime.
And the code is in great shape. If a potential investor wanted to send in their technical team for a review, I'd have no fear. Heck, I'm more confident than that: if another team were taking over the code base, I'd happily give them my cell phone number.
If you subsume the design into the implementation, then someone who goes looking at the implementation will have no way to distinguish between what was a design decision from what should be relatively arbitrary implementation decisions.
Well, that's only if one doesn't write tests and writes muddy code. If I want to know what a bit of code is supposed to do, I look at the method name, the class name, variable names, and the unit tests for the class. If those are good, then I don't need a spec. And if those are bad, generally the spec is useless anyhow.
But if I'd have to pick just one thing to be right, it would be the unit tests. Everything else, I have to check by hand. But the computer can check the unit tests for me.
I'd go a step further and throw a semantic error if suffeciant comment's were not found before certain constructs. Hell, make them part of the language.
Please don't make me kill you.
One of my least favorite things to do when taking on a new code base is to spend hours and hours deleting all the useless comments: the obsolete ones, the redundant ones, the misleading ones, the ones that are completely obvious, and the many, many comments automatically inserted by an IDE.
And people already do this even when the language doesn't require any comments at all. Of the last three code bases I've picked up, about 90% of the comments were worse than useless. I can't imagine what the ratio would be like if a fussbudget compiler required you to put in "// asdf asdf asdf" before every new method and every block.
People who are bad at explaining a precise algorithm's details in an elegant form using Java, C, Perl, or Python are also bad at explaining it in an elegant form using English, for the exact same reasons. They're just not good at communicating carefully and clearly in general.
Agreed! The solution to bad programmers putting out confusing structures in code isn't to get them to produce a parallel structure of documentation.
Uh, huh. Yeah. Steve Jobs personally signs off on the "functionality" of the Home/End key before each version of OS X ships.
Given the stories that people tell about Jobs's perfectionist micromanagement, that would not surprise me in the slightest.
The most productive people I know (lines of code per year) are emacs or vi users.
:-)
The people I know who produce the most lines of code per year are the least productive ones.
So selling a product at a profit isn't a real business? What would they have to do to count as a real business?
Real businesses are those that provide fair value for money spent. Real businesses are ones where if the customers had all pertinent information and plenty of time to think about things, they'd still do the deal.
How is selling something taking advantage of the customers?
I believe what the poster was objecting to was the many bullshit tactics that printer companies currently use to take advantage of customers. E.g., using the DMCA to prevent competitors from making reasonably priced cartridges that work with their printers.
The difference between Us and John Gilmore? We're not millionaires who think bureaucracy should be spat upon at every step.
I've met John Gilmore on a few occasions over the years, and I have never seen him act in an arrogant or overbearing fashion. He's always been mild, polite, and friendly. It wasn't until the third or fourth occasion that somebody mentioned who he was, and until then I had no idea; nothing about the way he acts conveys that he happens to be rich.
So unless you have some more evidence than his bank balance, maybe you can lay off the unfounded personal accusations.
Much better is an explanation over a block of 5-10 lines giving you an idea of what you are trying to achieve. Comment any thing that is not clear, like if your using bitwise shifts to multiply and divide, for example.
I used to write lots of explanations. I still do when I have to, but now it feels like a defeat to me.
Instead, I try to make the code readable enough that it doesn't need explanations. E.g., I'll take each of those 5-10 line blocks and do an Extract Method refactoring. The information that would have ended up in the comment ends up in the method name, in the parameter names, and in the return variable name.
Also, I put a lot of that energy into writing good unit tests. Comments can get out of date, but unit tests always tell the truth.
Don't put all your eggs in one basket.
Find a vendor you think will be good, have them break the project down into chunks of no more than a couple of weeks each. Have them do the first chunk only, with the understanding that if they do a good job, they'll get more work.
Then make sure the first chunk is done completely and well before giving them the next chunk. Accept no excuses or promises that they'll make you happy down the road. Do not give them the final payment until things are 100% complete. An incremental approach will substantially reduce risk of project failure.
Also, I strongly recommend that you pick somebody who writes unit tests and acceptance tests for their code. Having automated tests makes it much easier for other developers (yours, theirs, or new vendors) to work on the project.
Here is an idea, why dont you just fucking google it.
Here's a question I didn't find such a good answer to in Google: Was it really necessary to be such a prick?
If you would have read past the first question mark in the guy's post, he isn't just asking for the name of one place that's selling them. He's also asking when or even whether these systems will become common. For somebody who's about to drop tens of thousands of dollars, those seem like pretty good questions.
Funny, Google isn't coming up with such good answers on that. Boy, if only he could find a community of people who make their living on the cutting edge of technology. Maybe some of them would know! Perhaps you can share the Google query that will help him find somewhere like that?
It might not be abandonware, but I wouldn't bet my job or life on it.
Betting your life on the choice of a webmail package? Who do you run servers for, General Zod?
I deal with project managers from the oil, gas and chemical fields every day and these guys and gals are well trained at what they do. [...] Now, with respect to software, from what I have seen anecdotally there's just not the same kind of rigor placed on most software projects, even large, very expensive software projects. The upfront definition tends to lack the type of detail you see in other (physical) capital projects. [...]
This is a topic of hot debate in the world of software development. For many years, people have assumed that software development was like any other construction project, and that if you just applied more project management practices from those domains, software development would be better. This has not been broadly successful.
In the last five years or so, a set of approaches collectively known as Agile have arisen. They all recognize that unlike buildings or bridges, which include a moderate amount of design and a large amount of expensive, hard-to-change construction, software development is different. Software is mainly a design activity; we have automated most of the construction phase (via things like compilers). Software is, in a word, soft.
Agile methods take advantage of this difference, favoring continuous planning rather than trying to do all the planning up front.
So my advice to the original poster is to carefully study the agile methods like Extreme Programming or Scrum to see what you can learn from them. I've tried projects both ways, and I heavily favor the agile methods over the heavyweight ones.
Short version, config object, no singleton.
Amen. About 95% of the time I see somebody using a Singleton pattern, it's a very fancy way to have global variables.
This is a good start, but there are a couple of ways to improve.
First, Java's serialization format is pretty opaque. That makes debugging, testing, and schema migration a pain in the ass. A better choice is XML via XStream. If you have a good object model, its output XML is pretty readable. And you can improve that by adding custom adapters for particular objects. And for the XML-is-too-verbose crowd, let me suggest putting a GZIPOutputStream in the chain.
You generally do have something like GameMap or MobileObjectsHashTable though.
This is a good approach in Perl, but in Java you can do better. When I see classes with names like that, it generally means the programmer is thinking too much about implementation and not enough about design. Instead of GameMap, it should be Game. Instead of passing in string keys and casting objects when you (hopefully) get the right ones out, take advantage of the language's static typing and put all that work inside of the Game object.
For more on this topic, read the excellent book Domain-Driven Design.
My question is : WHO CARES ? I mean, what the hell, why would I want to know how many people were involved in the fabrication of my fridge ?
I care.
I care about the people who have contributed to the open source projects I use because they have given me a fabulous gift, because they're doing something good for the world. They rule.
I only wish more of them lived in my neighborhood, so I could buy 'em a beer. Any of you open-source developers who live near San Francisco's Zeitgeist, drop me a line and I'll pour you a glass of Racer 5.
They had 80 billions in the bank, why didn't they throw 20 billions in R&D to get loghorn out in time ???
Why? Brooks' Law might be the reason.
When they *started* doing Longhorn, it might have made sense to build three parallel development teams and pick the winner after two years. But now, adding people would likely make things worse.
Irresponsible PC users cause a lot of the major security issues in this connected world; you can't put all the blame on Microsoft.
I can sure try.
Microsoft is allegedly selling an operating system for average consumers and nontechnical people. Much of their target audience knows absolutely nothing about computer security and will do nothing to maintain their boxes. If they produce a product that the vast majority of their chosen market is known to be incapable of using responsibly, they should take the blame for that.
If it were utterly impossible to solve the problem technically, then maybe I'd forgive Microsoft and say that the government should require a license to own and operate a network-connected computer, along the lines of a driver's license and car inspection, or perhaps more like a building permit. But I think the problem can be solved entirely in software once Microsoft fixes some internal wetware issues.
So you think. It's all the rage now to have technial meetings where nobody speaks and all arguments are made through pantomime. I'm sure that's what he's talking about.
My favorite thing to explain that way is an elevator algorithm, although stochastic fair queueing is a close second.
Piling tons of extra work upon your programmers, and unrealistic deadlines, comes back to bite you in the ass in various forms.
Agreed! Bad (or just naive) managers focus on features and dates because those are easy to measure, and ignore reliability, productivity, and sustainability. That leads to the common phenomenon of having to do major rewrites every few years. This isn't inevitable; it's just the accumulation of a million tiny errors and mistakes. It's like tearing down and rebuilding your house every few years because you're in too much of a hurry to clean and maintain it.
My favorite thing about Extreme Programming is that it rigs the game so that managers can only adjust features and dates, not quality. And thanks to weekly iterations and a tight team environment, whenever anybody slacks off on quality, everybody feels the pain soon.
Remeber that you want your ISP to clamp down on illigal activity when you're trying to get a torrent of DVD rip or a newly release album on mp3.
If you read my post more carefully, I think you'll see that I'm not talking about what's illegal; I'm talking about what's bad for the neighborhood.
From a landlord's perspective, the problem with a crackhouse isn't that somebody's doing illegal drugs. If landlords kicked out every tennant who had ever smoked a joint, there'd be a lot of empty apartment buildings out there. The problem with a crackhouse is that it's an uncontrolled menace to the building and the neighborhood.
I don't much care whether the law formally recognizes the harm that spammers cause to the internet. (Sure, it would be nice, but our legislators' calendars are already pretty full doing the bidding of their campaign contributors; I doubt they'll have time for something that matters to mere citizens.) But I do care that network operators maintain an orderly network, and that includes cracking down on infected servers, hax0r kiddies, spammers, and other people or programs that abuse the network for fun and/or profit.
Additionally, I view credit cards as a fundamentally bad idea, because they make it very convenient and easy to spend money you obviously cannot afford to spend, because you don't have it.
This is a point with which I completely agree but is entirely irrelevant to the discussion.
Although I have no credit cards and never have, I can happily use the credit card network. How? I have a charge card, an American Express card: you must pay it in full every month. I also have a debit card, where the money comes directly from a checking account (in which I keep limited funds to reduce risk).
It does bother me that so many OSS projects use Paypal and/or credit cards as their primary system for receiving donations. [...] At minimum, they should accept personal checks.
You're missing the open-source spirit here. Telling a bunch of people what they should do is what you do with people who work for you, like the people you buy stuff from. In the open-source ethic, if you think the world should be different, you step up and change it.
The reason that most on-line entities don't take checks is that they're a pain in the ass to deal with and not many people want to use them. If you'd like to change that, then set up a service for OSS projects where you receive the checks and handle the hassle and then send them the money via PayPal or wire transfer.
All companies today use the following order 1. shareholders 2. shareholders 3. shareholders 4. company executives.
And your source for this information would be what exactly? I'm pretty impressed that you've managed to find out what all companies today do; there are a lot of them. Some companies that I know from the inside seem to have a different attitude, but I guess I must be mistaken.
J&J was in a shear panic over that incident.
A shear panic? Is that where you're so freaked out that you run with scissors?