A while back I read a book called Hard Facts, Dangerous Half-Truths And Total Nonsense: Profiting From Evidence-Based Management  by Bob Sutton and Jeffrey Pfeffer (http://www.amazon.com/exec/obidos/ASIN/1591398622/bobsutton-20). It's one of a rare breed of business books - not only does it actually make good, evidence-based arguments but it also stresses the possibility, and importance, of applying the scientific method to management, and to running a business. In the largely evidence-free world of management texts this is extremely refreshing.

The book examines and debunks practices that people assume work because they’re either common practice or common sense. Forced ranking, performance-related pay, executive stock options and management by cliché are all looked at and torn down.

Bob Sutton has also got an extremely interesting blog at http://bobsutton.typepad.com/ where he discusses his upcoming book “The No @ssh0le Rule”. It sounds fairly self-explanatory, but I’m sure that when it’s padded out to the obligatory 250-page business book length it will be a great read.

Sutton has also got a short and entertaining video about The No @ssh0le Rule at http://www.50lessons.com/sutton/.  I’m a firm believer in this rule, and I’m proud that we’ve managed to enforce it stringently at Red Gate. Obviously it’s impossible to avoid all contact with all @ssh0les all of the time, but Sutton’s advice to just let it wash over you is good. With practice you can go a step further and just remain good humoured and watch them with a sense of detached amusement.

How do you deal with @ssh0les? Do you work with one? Or for one?  Post your comments here …

(I apologize for the weird spelling of @ssh0le, but for some reason the site is protecting your tender sensibilities by replacing the correct spelling with ***).

There are very few good books about software and business out there. Here are some excellent ones:

Dilbert and the way of the weasel by Scott Adams
There's more good advice about running a business in here than there is in most 'proper' business books.

Peopleware by Tom Demarco and Timothy Lister
If you read one book about creating and managing software teams, this should be it.

The mythical man month by Fred Brooks
A classic.

The psychology of computer programming by Gerald Weinberg
Athough this book is 35 years old, it's still a worthwhile read, with interesting chapters on topics such as computer programming as a social activity.

Facts and fallacies about software development by Robert L Glass
The title says it all. An excellent book

In search of stupidity: Over 20 years of high-tech marketing disasters by Rick Chapman
Covers, among other things, the mistakes that Netscape and many other of Microsoft's competitors made.

Information rules – by Carl Shapiro and Hal Varian
Written at the peak of the dotcom boom, this is one of the only books to point out that profits still mattered, and that everything hadn't changed.

Showstopper – by G Pascal Zachary
An account of the deathmarch to ship Windows NT

The design of everyday things – Donald Norman
Read this and you'll spend weeks swearing at door handles and kettles.

Good to great – Jim Collins
One of the few business books out there based on hard research and facts, this examines the characteristics that companies that make the transition from good to great have.

Anybody want to suggest some more?

Ajax is the dancing dog of software development. Creating platform-independent, highly interactive, installation-free applications is a noble aim, and Ajax is a very clever solution, but it is not a solid foundation for the applications of the future.

Writing thousands of lines of Javascript, running as an interpreted language inside incompatible web browsers, communicating with web servers using slow and verbose data streams via stateless protocols designed for text-based hypertext systems is an absurd solution to the problem.

Abstractions will be developed to eliminate some of the pain. Frameworks such as Atlas will help ASP.NET programmers, and the Google Web Toolkit will help people using Java. But the underlying foundations will still be on sand.

Ajax might be the only – and a very clever – solution to the problem given current constraints, but rather than trying to create more and more hacks to overcome the constraints, shouldn’t we be removing the constraints?

There’s a lot of hype about Web 2.0 at the moment. Currently, it’s just a meaningless label stuck on a meaningless bubble of technology and marketing hype. Why not make it a real Web 2.0, rather than just a pointless naming exercise? Bin HTTP, HTML, XML, the web browser, and Javascript. Web 1.0 was a prototype. Throw it away and let’s do the next version properly.

I’m proud of the software that we write at Red Gate.  The people here produce awesome software that’s well designed, well written, well tested and well documented.  And we’re trying to scale up. A year or so ago we could run a couple of development projects at a time. We’re still a small company, but we can now run five. In a year, we’ll be running ten in parallel. What are we doing to make this happen?

At Red Gate, small inter-disciplinary teams are essential. Although each project has a leader, it’s important that the teams are small enough to manage themselves and don’t have much additional internal structure. That restricts the size of a project team to about eight people. It’s important to have people with different skills, backgrounds and roles on the team as well. Typically, a team will have a couple of developers, a couple of testers, a usability expert and a technical author. These people are all very different but, assuming the dynamics are right and the team gels, can produce a whole greater than the sum of the parts. Developers and testers have opposite mindsets – as a rule, developers do not make good testers, and testers do not make good developers.  As for usability people, they’re totally different beasts. To see what I mean, check out Dom’s blog and read about the crocodiles.

We try to bring the project team together and keep it together for the entire project. Obviously, people’s involvement changes as the project matures (for example, usability experts are involved more up front, and our technical authors later on), but we try to keep the team whole and not pull people off to work on other projects. We give the team a simple project brief, and ask that they do something very specific: ship quality software, on time.

It’s up to the team to decide exactly what they do, how they do it and when they ship. We provide some rules and some oversight but we give the team more or less total control beyond that. For example, we ask them to lay out milestones not more than two months apart. We ask them to prove that they’ve talked to real users. We ask them to demonstrate that they’ve thought about the problem. We give some guidelines about what they should do from design, testing and coding perspectives at each milestone. We ask them to persuade their peers that they can achieve what they say the can, in the timescales they claim they can.

Take the new version of SQL Prompt we’re working on. The team was given the following brief:

“Write version 3 of SQL Prompt”

They’ve talked to users, visited SQL developers in the area, done web surveys, followed up with customers with strong opinions on the current version of the software and talked to people in sales and marketing. They’ve decided what they want the product to do, have come up with technical and user designs for how they’re going to do, and decided when they’re going to do it by. They’ve analysed the risky areas of the project and have proved they can crack the technically difficult bits. They’ve persuaded a ‘Green light panel’ of their peers that they can ship SQL Prompt 3, with a solid set of features, by a certain date.

You’ll notice that I said we want the team to ‘ship quality software, on time’. The time and the quality of the software are more important to Red Gate than the feature set. We would much rather ship a limited piece of software that’s of awesomely high quality than a sprawling, under tested, product that checks every item on an arbitrary feature list. That means that the team has got the freedom to cut features if they feel unable to hit their original timescales. They won’t necessarily be penalised for making these sometimes inevitable decisions.

Since shipping high quality software on time is a behaviour we want to encourage, we reward it. Rather than handing out bonuses at the end of the year based on inappropriate metrics, or use some forced ranking system, we reward teams for shipping products on time. When a project is given the go-ahead, we assign a pot of money to the project, to be divided up on completion. If the end product is of low quality, the pot is reduced. If it ships a day late, the team gets no bonus. It might seem like an extreme pressure, but it’s proven a good way to focus people on shipping. Since the team has total control over the feature set, it’s not quite as brutal as it seems.

We’re trying to create an environment that fosters small, autonomous teams that ship software. We want decision making to be devolved, and we want the system to scale. We want to remove obstacles from the paths of our teams, and avoid unnecessary bureaucracy. Will it work? Check back in a year or so.