That was added after (in response to?) my comment post. The mods can do that, and thumbs up to them for improving this content-free front-page post.

This is a really terrible review. You could have said that Business Process Management (BPM) and Business Process Execution Language (BPEL) are important to know for this book. Or it's so esoteric that, if you need to know what BPM is, you already know BPM.

Actually, the word in the botnet IRC channels is that it's a dotNETclr.elop.trojan.

I don't know if there are domain experts or a client-base whose desires a traditional engineering effort can be aimed at. So the internal crowd get to be the client-base and to provide feature requests or feature enhancements themselves.

I can't work out if that's a good thing. Perhaps they'll be doomed like Sun to have a closed culture (as Valerie Aurora pointed out http://blog.valerieaurora.org/2010/02/13/sleeping-with-the-enemy/) which will only scratch the itches that people within Facebook need for Facebook. On the other hand, they've built a substantial internal culture which mimics a successful free software culture.

We've had to justify creating auto test suites where I work.

Over the last decade our product has grown from one code-base into three strands, each with separate customer foci, and we've had a healthy amount of staff turnover so that there are still brilliant, creative and skilled people working on it but some of the original knowledge has left us.

We found* numbers to justify that automated testing of existing features, applied later will protect against regressive changes. Even where there are complicated features which were not modular in design, or which lack good interfaces, the tests have saved us massive amounts of time testing by hand. The real win is hidden under something we didn't realise until later: creating the tests have forced us to really document what the features are and how they work**, sometimes from a unit-test level, sometimes at the interface level and sometimes in a top-to-bottom vertical slice. Once you have a record of what your software does, in a computer which is skilled at remembering exactly and repeating exactly what some former staff member told it a couple of years ago, you have a decent reason to be confident that your bug fixes won't cause more harm than good.

*: ballpark figures / educated guesses / made up.
**: We favour working code over comprehensive documentation, until our agile team is reassigned to other projects or leaves the company.

I'll bite: as long as the anyone in computer science writes software which is licensed with a disclaimer of warranty attached (even GPLv3 has "THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND") then they're failed engineers. Real engineers have insurance for liability and warrant that their work is suitable for its intended use. Sure, there are support contracts available but when the majority of the computing workforce produce software that's 'good enough' and it's sold, installed and used without someone meeting their duty to care for the impact of their work, then they deserve the label 'failed engineer'.

I put an SSD in as system disk on my desktop,and it made me feel like a 12-year old boy again (guessing parent poster was once girl). When I was 12 we had a 25MHz ARM-powered desktop (Acorn A5000) which had its system software in ROM and which remains my definition of snappy. Windows 7 with 4GB of RAM and 4 2.5GHz AMD Phenom cores is nearly as snappy; Kubuntu 10.10 on the same hardware was dead on.

But to reply to TFA: no, I want spinning storage for the terabytes of archives my life will create, and the availabiliy of another speed/capacity tier of data cache will mean I'm always going to be sold the option of having both.

I wish someone had suggested I and the team I'm in work in a flexible and agile way a long time ago. I'm a recent convert, so excuse my fanaticism.

The manifesto recommends:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

in light of the following principles:

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity--the art of maximizing the amount of work not done--is essential.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

It's the programming environment that works for dotNET developers (developers! developers!): Visual Studio plus ReSharper and the best of the platform flows from your fingers. Sadly, it's not the same as Vim or EMACS, where the best of the platform flows from your muscle memory...

QA in open source projects is volunteer work. You have the wireless cards and know that they don't work; Ubuntu's given you the tools to alter your configs and rebuild the kernel drivers into a working setup. What are the bug numbers where your patches are attached?

Canonical *don't* use their resources to employ QA team-members, nor to buy one of every piece of common hardware. Get your hands dirty and stop trolling.

My eyes hurt too if the brightness in the screen is above 15%, and most of the time the brightness is at 80+%. My HTC Hero adjusts the brightness automatically, and does a good job of being legible in sunlight and darkness.