One advantage of brick-and-mortar stores is that if you want something *today*, or want to look at the darn thing in person first, and *then* get it today, they have an incredible edge over online retailers. Not everyone wants to drive to a store, look at something, and then go off and find another place to get it, and then wait for it to arrive.

Honestly, I'm surprised you can't log in online to more stores, place an online reservation a product to pickup today (with a limited reservation window), and by the time you arrive the salesperson has exactly what you want, and a good idea as to what they might be able to upsell you on. They could very well be stealing business from online stores by pushing the "do you want it now?" angle. I'm not sure why they don't.

Service is dead though. Most of the staff in such stores aren't paid enough any more to give a damn beyond selling you the product with the highest commission, and it means that anyone with any sense steps inside the store already filled with skepticism. The only thing that seems to be remaining in that area (IMHO) is competing on return policies. If a place has a good return policy and you want a working product ASAP, it can be worth paying extra to get the thing you want, knowing that you won't be waiting for four weeks on an RMA if it's broken.

As someone who has spent an awful lot of time documenting *other* people's code over the last few years, I believe I can offer some insight as to how it gets that way.

IMHO, the big reasons for poor documentation tend to be either related to the self-interest of the developer, or insufficient time being allowed by management to create the documentation. On the self-interest front, we have:

- Job security: If it is apparent that replacing a developer is going to be costly due to nobody else knowing the tricks of the undocumented code, nobody is going to put their hand up to be the one doing the firing, as the resultant disaster from the replacement getting up to speed is probably going to be blamed on the one who did the firing.

- Artificial inflation of worth: If a developer knows the secrets of the code but their coworkers do not, they tend to look considerably more efficient and productive than their coworkers when working on that segment of code. This is so common that it's almost easier to list the cases where it doesn't happen, than where it does.

- Politics and currency: Knowledge of the code has value, and withholding that from others gives it value that can be used to buy favours from other people, or used to "punish" people who cross them.

- Lack of visibility: Poor commenting and inaccurate documentation is often only really noticed by people with the technical background to understand it. If the developer answers to a non-technical person, they can choose to get lazy about the things they don't strictly need themselves.

- Revenge: If the developer leaves, the next guy is going to have a lot of trouble getting up to speed. By withholding documentation, the developer can make sure the impact is greater, and is really felt.

- Hiding bodies: If the code is hideously broken, and the developer incompetent or inadequately resourced, having no documentation allows them to hide this for as long as possible whilst they look for a way to get out of the organisation, reputation intact. Let the next guy take the heat.

On the management side:

- Lack of understanding: Sometimes management doesn't understand that if documentation (and code cleanups) and forever withheld, the codebase will become an unmaintainable mess. Simple changes start to take forever, and complex changes never fully work due to the need to hack them in.

- No time: Sometimes documentation becomes a "work in the background" thing, where no time is really ever allocated for it, until some disaster strikes, and the same people cry "but where was the documentation". Writing documentation (eg. technical documents) takes time, not only from needing to refer to and test the code, but also to verify and proofread the whole thing. It never happens in magical zero-time.

- Job security: Similarly to the developer's trick, management can do this too. If they hold knowledge about how everything fits together, and it's not written anywhere, then it's going to be hard to replace the *manager*, for the same reasons.

- Artificial inflation of worth: Let's face it, the manager's manager is probably never going to really read any technical documentation- they're too far removed from it all. Who looks better: The manager who delivers work in eight months, or the one who does it in nine, with proper documentation?

- Short-term focus: If the driving factors are always the externally visible ones, and internal concerns such as code maintenance are always neglected (perhaps because the manager won't explain the necessity of this to the higher-ups), then documentation *will* be neglected. If the manager plans to move on in the medium term, they may not care if the project falls over in a heap after they leave- it's unlikely anyone will pin it on them, and it may not matter anyway.

And a last one that's in a class of its own: Inability. Not everyone can write documentation well.

Having worked on both sides of the IT support fence, I like the plumbing analogy.

If the plumbers started mandating toilet times and protocols, and required you to get management approval for each piece of toilet paper you planned to use, a month in advance, then you have a problem.

If the company employees insisted on their right to relieve themselves in their offices, and demanded to know why someone isn't there in five minutes to clean up after them, you also have a problem.

If your IT department are blissfully ignorant as to the needs of the organisation, and there is no oversight of what they do, then you have a problem.

If your IT department are forced to jump on demand, and are never given the chance to address network security, stability, or backups appropriately because they are always supporting random device X that has nothing to do with the job (until data is lost, and everyone suddenly remembers that backups *are* needed), then you have a problem.

As with many things, there is a healthy balance between the extremes that a company should be aiming for. It's all common sense, and sometimes, it's not all that common.

> A battleship that has shown its willingnes to keep firing all guns until all atoms previously making up any knife-wielding attacker is at least in earth orbit, preferably in sun orbit.

Well said.

If the size of the battleship doesn't give you pause, climbing over the charred remains of the last few knife-wielding attackers may.

You know, they might not be so rare if every do-gooder with a time machine didn't keep going back in time and picking up all of the remaining copies before they were found.

> Ever wonder why you see so few patent lawsuits from IBM relative to their portfolio?

Personally, I just assumed it was the same reason that you see very few knife attacks on the hull of a battleship.

> well they make hardware (motion capture sensors) for a niche market. So it's not terribly likely that their code being stolen will be a big issue, I think. It's a tiny market with few players. In fact, having the code open might make their hardware easier to integrate for some clients with custom solutions, or at least feel safe about it.

Hardware manufacturers can potentially be good candidates for open source software, since they can release the source, and sell the hardware. If it's a small market or the hardware is expensive, they probably won't gain much from hobbyist contributors, so the question as to whether or not a company is likely to use the source and contribute back becomes more important. Of course, the modifiable source could end up being a selling point as you suggest. :)

> If the cloner comes with a name like IBM, Google, MicroSoft or HP, they can be 3 years behind and still get the contract... nobody ever got fired for choosing ________.

If one of the big players starts intruding into your market, you've probably got a real, business-killing problem to deal with, unless you can satisfy a need that they can not or will not satisfy themselves.

But then again, sometimes they come bearing money instead, since they want the product, but don't want to develop it from scratch.

> Even if your competitors do then take that idea and steal it, it's possible to make money from the fact that your version is always months ahead in innovations. It's easier for someone who is actively inventing ideas to keep the flow of research moving forward, compared to someone that who just copied a subset of their ideas.

This is a very good point. If the product is such that you can keep improving it, and keep those improvements in the eyes of your customers, then anyone cloning the product will be seen as just playing catchup. It then becomes hard for them to compete on anything but price, which is hard to do if they're hiring double the number of developers as well. Heck, open sourcing your last version and charging for your most recent one would probably be one way to keep clone-based competitors from even *starting* to nip at your heels. I'd say there are probably lots of ways of playing it, depending on the type of product, and the potential benefits of opening some or all of the source in those circumstances.

Consider:

- Is your product something that hobby developers might take an interest in? Will their contributions add value to your codebase or company? Will they want to contribute?

- Is your product something other companies might find useful if they took it, added a feature, and contributed it back to you? Will they have any incentive to send anything back to you?

- Do you have anything that you can subsequently sell to the people using your open code, that they are going to want to buy, that a competitor can't quickly spring up and take the opportunity from you?

- Could opening the code allow you to steal away a significant part of the market, that you can later sell products or services to, for a net profit? Is this likely?

And weigh this up against:

- You've given away the code. Is there anything left to sell, and will people want to buy it?

- Would your company survive if someone saw the code, thought it was a good idea, and put double the number of developers on it and told them: "make something like this"? Assume they will use your code as a reference, but no proof of it will ever be found.

- A company with an international presence steals your code, builds it into their product, and sells it. Do you either have the resources to fight a huge multinational (possibly hiding behind a subsidiary in a different country), and the ability to survive for a few years whilst it works its way through the courts, as well as fight off baseless countersuits? Or is your product such that your company will survive, even if it is being ripped off, possibly even benefiting from the exposure?

I think that it's great that you've been able to run Windows for so long, and experienced no driver or stability problems. You definitely should receive some sort of award or official recognition.

Anyway, I'd love to chat, but it's Monday and Suzy's PC is infested with malware again.

A downmod for a post making fun of an attack piece, and an upmod of the attack piece? Stay classy.

Hairyfeet, I'm not 100% sure, but I get the feeling you *might* personally have a preference for using Windows operating systems over Linux-based ones. If you could respond with a few hundred more inflammatory words to let me know for sure, that'd be just peachy.

Also, did you have a traumatic experience using a commandline when you were young? Possibly lost family members due to an accident involving a poorly-formed regular expression? Just curious.

My personal, unverifiable, unscientific, pulled-out-of-my-rear theory is that the development of life similar to and understandable by our own is sufficiently rare, and the universe so imperceivably large that the countless life that has evolved (we'll just say billions of instances in a suitably chosen near-infinitely-tiny fraction of the universe), just haven't *found* each other for the most part. Perhaps we're just unlucky enough to be located sufficiently far from other life, and there are billions of interactions between billions of similarly evolved lifeforms in some areas of the universe. Maybe heavy interaction between such lifeforms is the norm, and we're just part of the smaller fraction who are pretty isolated. Perhaps we are the front of life spreading into a new area, or the result of life dying off in the same area. But even that is probably overstating our importance.

Going with the above, Earth is definitely special case within a certain area, if we extend that area out until just before the closest instance of the uncountable number of other cases that meet the same criteria. :} It certainly seems to be quite unique within the area that we can currently perceive and understand. Perhaps this will change one day, when we can better understand the universe around us. Or perhaps we'll have died off long before then.

Anyway, that's how I like to look at things.

Short version: Tiny fractions of an imperceivably large universe.

Looks like Apple wants in on the patent extortion rort.

Apple's competitors can pull the same tricks too- I'd fully expect a few "innovation startups" to spring up soon, preloaded with patent portfolios, and start hitting Apple back.

My hope is that in the resulting mess a few senior people in the bigger organisations take notice and figure out that they could make huge savings by spending some of that money on political lobbying instead, get patent laws cleaned up, and pull the fangs from these lawsuits. These organisations have made great efforts to get the cheapest manufacturing, labour, and development costs. It seems strange that they haven't gone for similar savings in the legal area as well.

But I know that I'm hoping for too much.