Aquamation may supercede cremation due to releasing less greenhouse gases and otherwise wasting less of the body's nutrients.

There is a major problem with the approach you have described: it builds inflexible organisational silos where cross-functional business processes are extremely expensive to establish (due to interoperability issues politically and technically), operate (due to forgoing economies of scale possible with rationalised, consolidated technology investment) and adapt (due to the impact on existing complex interdependencies resulting from point-to-point integrations). This is particularly problematic for companies that have a complex arrangement of multiple customer service channels (e.g. retail presences, call centres, websites) and multiple loosely-related product/service offerings (e.g. sale of goods, provision of services) -- doubly so when this occurs under a unified brand.

The issue is that with every functional business unit owning their individual line-of-business applications, each with its own business rules, state management, reference data (e.g. customer identity/contact info) and transactional information (e.g. purchases), the organisation can fail to leverage important cross-selling, customer acquisition and retention opportunities, never mind falling afoul of regulatory compliance issues. Simply put, the left hand doesn't know what the right is doing and the customer experience suffers, causing the company to suffer. Centralised full-function IT has its place, though you may be able to federate decentralised departmental development capabilities with a combination of governance and technology (e.g. the SOA approach).

While the technology environment can degrade over time due to poor processes, just as important is getting it right in the first place. In my experience, the IT team often lacks any architectural capability when the department is set up, typically because it's "too small" or their needs are "simple". As a result, nobody with the necessary qualifications/experience/mindset really thinks about the business' strategic requirements, they just go for "best practice". Unsurprisingly, "best practice" by itself simply means whatever fad the technology industry is pushing at the time.

Many of the posters above are right in saying that simply throwing it all out isn't the solution, however, throwing away all the assumptions, determining the strategic requirements and then reconciling those with the existing landscape is the way to do this. Sometimes that then results in things being replaced, but sometimes it does not.

Every other business unit does (or should be doing) this during the corporate strategic planning cycle, why does IT not? Sadly, the reason is normally the organisation only really has one "primary" business unit and it excludes IT from the strategic planning altogether. It's IT's job to convince the decision makers that they ought to be partners in strategy, but IT's normal lack of rigour in processes and particularly in financial management that prevents them from having the ammunition to fight for a place at the table.

Alternative breaking options:

* falling on its edge and cracking
* repeated extreme heating/cooling cycles causing the disk to crack

This is how I do it, too, asking first for the difference then for examples of where you'd use each. I find it's much more time-efficient than programming exams.

SSLed checksums for the binaries... oh, wait, Mozilla doesn't bother publishing those, for some reason.

Not an old wives' tale at all. The brighter the level of light available (and contrast), the less your pupils have to dilate and the greater the depth of field you'll experience, resulting in less continuous adjustment of focus and hence less eyestrain.

We use CounterSoft's Gemini bug tracker for managing tasks. It's easy to use and what's most important for us is that you can define your own workflow, not be bound to what works for other people.

It's ironic that with respect to best practices you happened to choose "an IT bible ... that spelled out procedures for running an IT shop": it's called ITIL. Anyone in IT should make themselves familiar with it and benefit from decades of tried and tested best practices. They were true long before modern commodity technology but are still applicable. Admittedly, anyone who claimed their product is critical to any of these process-oriented best practices is spouting crap.

You've also completely missed the point with SOA: it's not about Web Services, it's about business service orientation. It's an approach that can be used to design systems that work like their organisations, promoting ownership, the lack of which can make even the most technically correct systems not just worthless but a negative influence on the company.

Unless you're specifically referring to the D&D ruleset Dragon's Age: Origins should keep you happy for some time.

Examples of RPG/FPS merging well: Deus Ex, Morrowind, Gothic 2, Vampire the Masquerade: Bloodlines, Star Wars: KoToR, Oblivion, Fallout 3.

Probable near-future examples: Alpha Protocol, Borderlands, Mass Effect 2.

RPG isn't dead and has dramatically improved ever since Pool of Radiance :)

I understand what you're saying, insofar as a real developer has the motivation, background knowledge and aptitude to learn on their own initiative.

However, for the benefit of newbies (so they don't dismiss the concept of training out of hand), when a project on a tight timeframe comes along that requires a specific and new skill set, it's normally quicker to send the developer on a dedicated training course than wait for them to figure it out themselves, or to hire a contractor with the necessary skill.

There's a world of difference between an accidental trespasser immediately leaving the property and one posting photos taken of people who have an expectation of privacy then posting them on the Internet.

Once such a photo hits the Internet, just removing it will not magically delete it from everywhere it has been distributed to.

Many companies have standardised on sans-serif fonts for internal documents to optimise on-screen readability. These then get printed before meetings, etc and thrown away shortly thereafter.