If you want to hear Joel Spolsky, Rick Chapman, Dan Nunan, Jennifer Aaker, Jeff Pfeffer, Tim Lister, Matt Mason, Guy Kawasaki, Hugh MacLeod, Tim Lister, Bill Buxton and Alberto Savoia speak on the Business of Software in San Jose, October 29th-30th, then you’ve got until the 20th October until the pre-event discount expires. Go to www.businessofsoftware.org for more details.

Red Gate is hosting a party in Cambridge, UK to celebrate Slashdot’s 10th anniversary. There will be free food and drink. You can sign up at http://slashdot.org/anniversary.pl?view_id=553

I hope to see some of you there.

Often people from outside a field bring an interesting perspective. It took a physicist (Richard Feynman) to decipher the Mayan Dresden codex (it described the movement of the planet Venus, not the actions of the gods). It’s taking a businessman (Bill Gates) to revolutionize global health. On a smaller scale, bringing an outsider with a different perspective (a designer, say) into a software team can change what they do. In this vein, this week’s guest post is by Matt Mason, author of The Pirate’s Dilemma. Matt’s background is as a pirate radio DJ, music journalist and magazine founder. Here, Matt outlines how piracy has consistently changed our world for the better, and will continue to do so:

There was a time when many people didn’t think of software as property at all. Thirty years ago everyone from multinational corporations such as IBM to hobbyists programming in their garages for fun, treated software as information – a public good. But that all changed on February 3rd 1976, when a 21 year-old programmer wrote to an open letter to a gang of hobbyists who called themselves the Homebrew Computer Club, saying they could no longer use his software anymore, a program called BASIC, without paying for it. “Who can afford to do professional work for nothing?” the letter asked the club, who huddled together in a garage to do exactly that. “What hobbyist can put 3-man years into programming, finding all bugs, documenting his product and distribute for free?” he asked. The young programmer had a point. Why shouldn’t he be paid for his time? Personal computing had reached a fork in the road.

The letter-writer, one William Henry Gates III, or Bill Gates to his friends, managed to turn the tide of opinion in the programming world, and ended up scratching a pretty good living from his software, too. As did some members of the Homebrew Computer Club, such as Steve Jobs and Steve Wozniak. But when Microsoft unveiled Vista last year, a product 10,000 programmers had spent almost five years developing, many software people were already predicting it might be the last of its kind, because the way software is both produced and consumed has changed. Once again software has reached the same fork in the road, only this time it’s not just the software business facing this dilemma.

In every industry in the world, the line between information and property is blurring. In software this has clearly been underway on for some time – from open source alternatives such as Linux, to rampant software piracy, trying to define software strictly as property has been a constant problem for programmers. Now it’s also a problem for those in music, the movie business, the pharmaceutical industry, fashion and many other areas. We’re all at this fork in the road that I call the Pirate’s Dilemma. But instead of taking one route or the other, thinking of software as either information or property, maybe this time, the answer is to think of it as both.

Throughout history, there have been other groups like the Homebrew Computer Club who have gotten together to work out better ways to do things, in situations where copyright laws don’t always work. In 1960s Jamaica, an accident in a recording studio led a DJ to realize he could create amazing new forms of music by creating space for the audience and other DJs to collaborate with the artists on the original recording, a revelation which doubled the profitability of that record label, created several new types of music, and birthed what we now call the remix.

In 1970s New York, graffiti artists from diverse backgrounds and warring neighborhoods united and formed “crews” that were able to move across the gang-controlled boundaries, and develop one of the most explosive artistic movements the world has ever seen, using an informal, norms-based system that protected their work, but encouraged other artists to innovate and learn from them.

In the 1980s, three eleven-year-old kids realized video games were a lot more fun if you hacked into the code and re-wrote the story yourself. Their first hack showed every other fan that video games were as easy to manipulate as coloring books, and two decades later, “modding” as it’s now known, became a vital part of game development. Game developers encourage fans to hack their games, because it’s a great way for them to develop new ideas, find the most talented people, and extend the shelf life of the original game.

Thanks to the internet, in the late 1990s it became very obvious that information as we know it is now a two way street, whether we choose to define it as property or not. Sometimes we do need to think of this a problem, and try and stop others from using our property as information – that’s always going to hold in many cases. But not all the time. Often it can be incredibly beneficial to open up your information to others. Different perspectives bring new ideas, solutions and sometimes even entirely new business models that we couldn’t see before.

Finding innovative ways to let people to share information without risking our intellectual property will define the software success stories of the next few decades. The writing has been on the wall for some time; the game has quite clearly changed. There is no fork in the road, what lies ahead is actually a road with two lanes, which together add up to a more efficient way of getting where we need to be. 

Want to hear more about Matt’s ideas? Matt will be speaking at Business of Software 2007. Or check out his blog.

Enjoyed this post? Subscribe to our RSS feed.

My latest post is over at the Simple-Talk web site. Here’s an extract:

At SQL Pass last week, Tom Casey – General Manager for the SQL Server Business Intelligence unit at Microsoft – made the point that "SQL Server is not really a database – it is a database platform and it has been a shift from a relational database to an end to end solution".

You can read more, and vote, at Simple-Talk.

Tell me about yourself. Write a blog post. Draw a picture. Name 10 things that are green.

These are hard things to do: they are too generic. Provide constraints and the tasks become easier: tell me what you did at your last job; write a blog post about profiling SQL Server; draw a self portrait; name 10 green things that you might find in your fridge.

Blank sheets of paper are scary: we work better when we’re given limitations. Not only do constraints make tasks easier, but they make them easier to do well. Rather than ramble, we focus and provide better, more structured, answers.

The same is true for software. Software is best when it’s specific, not generic. If you frame the problem tightly (write software to compare and synchronize Microsoft SQL Server databases) then it’s easier to solve, and solve well, than when framed loosely (write a database tool).

The same is also true for people. Although, apparently, we work better and are happier when we define our own goals, that blank sheet of paper can be paralysing. Total freedom is counter-productive: to be happy and effective, we need constraints. The constraints are almost arbitrary: it does not matter what the constraints are, just that there are constraints.

So, next time you or your team is flailing, try imposing constraints until the problem you are working on becomes solvable. If you cannot come up with reasoned constraints then try arbitrary ones.

The Micro ISV dream is that of quitting your day job and setting up your own one-man business. Instead of slaving away to make other people rich you can leave your cubicle behind, spend a few hours a day with some light coding and relax while the money rolls in. But is this possible? Can you afford to leave your job? Or should you get a job in a bar instead to get that extra income?

A handful of Micro ISVs are extremely successful. A Micro ISV can sell more than $50,000 a month. These rare successes skew the numbers for the majority of Micro ISVs though. Most one-man bands earn under $25 / hour. The most common number of sales per month is none. The most common amount of sales / month is no dollars. But the outlook isn’t quite as grim as those numbers make out. Read on to get the full picture.

I ran a survey on the Joel on Software forums a couple of weeks ago. 96 people replied. Here are some of the results (you can find the first part of this write-up here). Note that one issue with this survey is that it’s surveying JoS regulars who have the time and inclination to answer a survey: it’s not randomly sampling all Micro ISVs.

The definition of Micro ISV is loose. Some people think of Micro ISVs as being just one-man bands, for others it’s a synonym for small business. This survey side-steps the issue and only asked people who called themselves Micro ISVs: they are self-classified Micro ISVs. Here are their sizes:

As you can see, most Micro ISVs are a single person. Just 10% of all Micro ISVs consist of more than 2 people.

The average (mean) number of downloads or trials / per month is over 3,000. This is, however, skewed by some outliers [as with all these graphs, beware of the differing bin size which can be misleading]:

Although downloads and trials are important, it’s sales that really count. Again, some highly successfuly mISVs skew the numbers. The median sales / month is $2,000, but the mode (the most common sales figure) is zero:

Actually, it’s not sales that really count. It’s profits. Unfortunately I didn’t ask that question.

The average conversion rate is almost 8%, but under 3% is much more common:

Although some Micro ISVs sell products for more than $50,000, most products are priced at under $65:

The amount of time people spend working on their mISV varies, from almost nothing to over 80 hours per week. The average (mean) is about 25 hours per week:

The biggest issues that Micro ISVs face are time, motivation, sales and marketing:

I drilled down into the data and examined single person Micro ISVs who had been in business for 6 months or more (on the assumption that they should be earning money by then). Based on the hours / week and sales / week, and ignoring expenses, here are the hourly salaries:

A lot of people earn nothing at all. Half of people earn under $25 / hour. But some people earn $200 or more / hour.

Interestingly, there is only a weak correlation between sales and hours worked. There is, however, a moderate correlation (Spearman’s rho=0.55, p < 0.01) between months the mISV has been going and sales. In other words, there’s only a weak link between how many hours a Micro ISV is currently working and their revenue. How long they’ve been in business is a better indication of how much money they make. Of course, this could be because older businesses are, by definition, those that have not failed, and people making money now might be coasting on past successes.

So what’s the conclusion? Most people don’t have the time, motivation, marketing or sales skills to make it big as a Micro ISV. And running a Micro ISV can take up a lot of time. It’s an interesting hobby, but most people don’t make enough money to quit their day jobs, and the odds are they never will. But it can be done.

Enjoyed this post? Subscribe to the RSS feed.

Download the raw data (169.5K) for the survey results

How much do you sell? What apps do you write? How many downloads do you get? These are questions often posted on the Joel on Software forums. To answer some of these questions, I’ve surveyed the Micro ISV community who visit this forum. I got a good response, with 96 people answering. This is the first of two posts describing the results. I will cover mainly demographic information about the responses in this post. Next week, I’ll write up the results about downloads, revenue and so on.

I asked an open question about what type of applications people sell. I then categorised the answers into application category and platform type. Most people write desktop applications, with only 12% writing just web applications:

This is probably a good indication that Micro ISVers haven’t been taken in by the trendy web 2.0 fad. The application category was split evenly between consumer and business, with 16% of people writing developer tools:

Again, this is slightly unexpected. I had the misconception that Micro ISVs often started out by writing developer tools. This often seems like a cool thing to do, but it’s a hard market to get into.

20% of all Micro ISVs have been running for under a year, but 8% have been running for more than 10 years. The average (mean) age of a Micro ISV is a bit over 4 years. The mode (the most likely running time) is 1.5 years, and the median 2 years 7 months. In the below graph, the bimodal distribution is misleading because of the different sizes of the bins. The lower bound of the bins is exclusive, the upper bound inclusive (eg 2 – 3 years means more than 2 and less or equal to 3).

The following graph show people’s current ages. 75% of people are under 40 years old. The mean, mode and median are all about 35 years old:

The next graph shows the age at which people started their Micro ISV. About half of people are under 30 when they start, with almost nobody over 45. The mean and median age is 30, with 25 the most likely age that people start their Micro ISV.

Finally one result that’s interesting, but possibly not shocking. Out of the 96 respondents, only one is female:

Next week I’ll write up the results showing the number of downloads and sales Micro ISVs have. I’ll also analyse the top issues that they face. Make sure you don’t miss out, and subscribe to this blog’s RSS feed.

Alberto Savoia is on a mission: He wants to banish crappy software, or at the very least, remove any excuses for its existence. His company, Agitar Software, is making people pay attention to testing and how it should be done, winning a couple Jolt awards and a Wall Street Journal Innovation Award.

Savoia will present “Better Code: Recognizing, Avoiding and Sanitizing Crappy Software” at the Business of Software conference (www.businessofsoftware.org). Bob Cramblitt spoke to him about the cause and effects of crappy software, a Google-like approach to software quality, and how testing can be a beautiful thing.

Cramblitt: Your company is named Agitar Software and you are a self-proclaimed agitator.  Where are you doing your most serious agitation these days?

Savoia: My mission and passion is to help developers take responsibility for, and succeed at, unit testing their own code. There’s an obvious and beautiful symmetry between code and unit tests: every piece of code that does something non-trivial should have a set of unit tests to make sure that it does the right thing – and continues to do the right thing as the code evolves. Unit tests benefit everybody: developers working on the code today, the developers who inherit the code, QA, and – of course – end users.

Today, unfortunately, the organizations that are serious about unit testing are a minority. I plan to keep stirring things up – agitating if you will – until developer testing becomes the norm rather than the exception. I expect that this will keep me busy for a few more years.

Cramblitt: Why don’t software developers test or test better than they do?

Savoia: I used to say that there are no excuses for developers not providing thorough automated unit tests for their own code, but I have softened my stance a little bit. Developers actually do have some excuses for not testing as much as they should.

Test development is hard; it’s a combinatorial problem and it can consume a lot of time – especially if you don’t use some test automation technology. We have found that, on average, for every line of Java code, you need 3-5 lines of JUnit to achieve adequate code coverage. When you look at the kind of code most developers have to deal with, and the amount of time they are given to do their work, you realize that the schedule they are given doesn’t have much room for testing. And – amazing as it sounds – there are development managers who don’t want their developers to “waste time” writing unit tests: “Just get the features in and let QA decide if they work or not.”

With this short-term perspective and schedule restrictions, it’s not surprising that even some well-meaning developers don’t unit test as well or as much as they should.

Cramblitt: You once said that crappy code is often defined as code you didn’t write yourself. Can you elaborate?

Savoia: A few months ago, I saw a guy wearing a T-shirt that said: “Hell is other people’s code,” an interesting take on Sartre’s famous quote: “Hell is other people.” Like almost all developers, I got into programming because I loved the idea of using code to create something new and useful from basic components – coding is like playing with Lego for the mind. When I first started, I couldn’t believe that people were willing to pay me so well for doing something that was so much fun. Inheriting and having to maintain a steaming pile of legacy code that someone else wrote, on the other hand, is real work – hard work – and, for many people, crappy work.

Cramblitt: Is crappy code in the eye of the beholder or are there objective ways to define it?

Savoia: There is no fool-proof, 100% accurate and objective, way to determine if a particular piece of code is crappy or not. However, our intuition – backed by research and lots of empirical evidence – is that unnecessarily complex and convoluted code is the most likely to elicit the “crap response” by the poor developer who has to inherit it. Furthermore, since complex code is particularly hard to test, crappy code usually comes without any automated tests.

Since the combination of complexity and lack of tests are key factors in making code crappy – and a maintenance challenge – my Agitar Labs colleague Bob Evans and I have been experimenting with a metric based on those two measurements. The Change Risk Analysis and Prediction (C.R.A.P) index uses cyclomatic complexity and code coverage from automated tests to estimate the effort and risk associated with maintaining legacy code. We have implemented a free, open-source, experimental tool called “crap4j” that calculates the C.R.A.P. index for Java code. We need more experience and time to fine-tune it, but the initial results are extremely encouraging and we have started to use it in-house. Crap4J is implemented as an Eclipse plug-in and people can download and experiment along with us by going to SourceForge and searching for “crap4j”.

Cramblitt: Good code can become crap when it changes hands.  How does a company ensure that code can be maintained and improved after the original writers are no longer involved?

Savoia: Since the actual work will have to be done by individual developers, the company should take time to train each developer on the proper way to deal with legacy code. The book Working Effectively with Legacy Code by Michael Feathers should be mandatory reading for managers and developers alike. Here is a quick overview of the main directions I would give to a developer maintaining someone else’s code:

1) Make sure you have tests for a particular piece of code before you change it. A test suite is a beautiful thing to have and it will give you a safety net as you make those changes. If you are working with legacy code and have no tests, you should become an expert at writing tests that capture the original behavior of the code before making any changes. Michael Feathers calls these tests “characterization tests.”

2) Once you have tests, refactor the code to reduce complexity and make your maintenance work cleaner. Method extraction is my favorite refactoring; it’s fast, safe (especially if you have tests), and easy to revert if needed.

3) Rename cryptic or ambiguous identifiers. This is a pet peeve of mine. In this age of cheap computing resources there’s no excuse for using a variable name like “ac” instead of “areaCode.”

4) Delete. If you can identify dead, useless, redundant or obsolete code, get rid of it.

In other words, leave each piece of code you touch in better shape than it was before you worked on it. You can use “crap4j” or some other metrics tools that measure complexity and code coverage to make sure you are on the right track.

Cramblitt: You’ve said that an application with a crappy code base can still be extremely useful or wildly successful.  What are some examples of this and why are these apps successful?

Savoia: With some rare exceptions, the most successful and long-lived applications tend to have the crappiest code bases. To understand why this is so, we need to understand the difference between a software application and the code for that application. Software is the finished product, what the user uses and experiences. Code is what makes up the software and what the developers use and experience. Those two experiences can be as different as the experience of a diner enjoying a sausage and that of the meat processing workers making that sausage. The user of the software is shielded from the nastiness of its inner working.

How successful software usually leads to crappy code is easy to understand: application success means long life, and long life means maintenance and adding features, support for new platforms, etc., while maintaining backward compatibility – something that’s very hard to do cleanly. The more used and widespread an application is the worse the problem – think of the compatibility and configuration challenges that Microsoft developers have to face with Windows.

Cramblitt: Even if an app is successful, is it only a matter of time when the crappy underlying code will make the app topple like a house of cards?

Savoia: In most cases successful crappy software is not allowed to topple because it’s too important to the business. But keeping it upright and functioning requires continuous heroic efforts and consumes a tremendous amount of money and resources. The opportunity cost due to crappy code is huge.

Cramblitt: What’s the most important thing developers can do to avoid crappy code?

Savoia: The answer is pretty simple and, by now, it should not be surprising. I can phrase it as follows: If you write code, write tests for it.

Write tests whether you are writing new code, or maintaining existing code. The simple act of writing tests has many beneficial side effects beyond the obvious ones. It forces you to keep the code simple and testable. It forces you to think about your code from the user perspective – which often results in better design and more natural interfaces. It helps you discover corner cases and exceptions before they byte you. And so on. You know how doctors say that if they could put the health benefits of exercise in a pill, it would be the most prescribed pill in the world. I feel the same about testing. Think of tests as exercises for your code – the best thing you can do to keep your code healthy and in shape.

It’s hard to have a thorough set of tests if the code is hard to test, and to make code easy to test it has to be relatively simple to use and understand, it has to have minimal dependencies, etc. So, if the code is accompanied by a thorough set of tests chances are that it will not be crappy.

Cramblitt: A couple of years ago, InfoWorld quoted you as saying that Agitar wants "to do for software quality what Google has done for search quality." How do you intend to achieve that and how are you doing so far?

Savoia: I was director of software engineering at Google before starting Agitar and saw first-hand how a bunch of very smart people, armed with huge amounts of CPU power and a very sharp focus on solving a very difficult, but clearly specified, problem can achieve amazing results. Agitar is focused exclusively on the very difficult problem of test automation and, in addition to hiring the brightest people we can find to do research and develop solutions, we have also made some significant investments in computing resources. The latest version of our flagship product, AgitarOne, can generate over 250,000 lines of JUnit per hour – that’s roughly equivalent to 1,000 very productive programmers. On top of that, our generated tests now achieve an average of 80 percent code coverage.

Like Google, we are pretty generous with our technology and resources. For example, we offer a free hosted version of our test generator at JUnitFactory.com. I’d say that we are well on our way to do for software quality what Google has done for search quality.

Cramblitt: You contributed a piece called "Beautiful Tests" to the new O’Reilly book called Beautiful Code.  What are the principal attributes of beautiful testing?

Savoia: The main purpose of tests is to instill, reinforce or reconfirm our confidence that the code works correctly and efficiently. Therefore, to me, the most beautiful tests are those that help me maximize my confidence that the code does, and will continue to do, what it’s supposed to. Because different types of tests are needed to verify different properties of the code, the basic criteria for beauty vary.

There are tests that are beautiful for their simplicity. With a few lines of test code I can document and verify the target code’s basic behavior. By automatically running those tests with every build, I can ensure that the intended behavior is preserved as the code evolves. I love tests that take minutes to write and keep paying dividends for the life of the project.

Then there are tests that are beautiful because they reveal ways to make code more elegant, maintainable and testable. In other words, tests that help make code more beautiful. The process of writing tests often helps you realize not only logical problems, but also structural and design issues with your implementation. Writing tests forces you to put yourself in the shoes of a user of your code and that’s an invaluable perspective.

Finally, there are tests that are beautiful for their breadth and depth. Very thorough and exhaustive tests boost the developer’s confidence that the code functions as expected not only on some basic, or handpicked, cases, but in all cases.

[Enjoyed this article? Subscribe to this blog’s RSS feed]

What are you doing at the moment? Not this week, or today, but right this second? You’re reading this post, and I’m guessing you shouldn’t be. You have more important things to do. Guessing again, you arrived here from some other distraction: an e-mail arrived, your RSS feader popped up a message or you linked here from some other web site you don’t have time to read.

You’re probably not one of those super-organised people who divide their day into timeslots: an hour for e-mail in the morning, 30 minutes surfing over lunch and then an hour for e-mails in the evening, leaving large uninterrupted thinking zones for most of your day. I’m certainly not: I’m always getting distracted and I check my e-mail obsessively. I know that I shouldn’t, and I know that it’s unproductive: the context switching is a killer. But often I just can’t stop myself.

A few weeks ago I came across a bit of software called DoNotDisturb. You load it up and it will ban you from using certain applications. I ban myself from browsing and checking my e-mail for an hour at a time. In case of emergency browsing I can, however, enter a 64 digit code to override it.

I thought it was such a great idea that I bought the rights to distribute it for free for a few months to the readers of this blog. You need this software. To get it for free (it’s usually $20), download it here.

(PS, you can subscribe to the RSS feed for this blog from here).

A couple of months ago at its annual convention in Detroit, the National Association for the Advancement of Colored People (NAACP) held a mock funeral for the “N” word. A symbolic gesture, sure, but not without its impact.

I was reminded of that event when I heard recently that someone was “more than deserving” of an award. It also made me think of the baseball catcher who was “very average.” Small things compared to the “N” word, but not without their erosive effects.

In the software business, and technology in general, we have a thriving culture of these phrases, swarming around our ears like a cloud of gnats or Outkast’s “Hey Ya!” (http://en.wikipedia.org/wiki/Hey_Ya!) in the fall and winter of 2003.

Many people are a) oblivious b) have been vaccinated or built immunity over time or c) think there is still value in these words. For the rest of us, they can still cause a psychic rash or at the very least, make us turn off our message receptors.

I’ll give you a few of mine to get started and hope that you’ll return the favor, no matter how painful:

easy to use
robust
intuitive
intelligent
state-of-the-art
flexible
low-cost
seamless
monetize
wizard (as a synonym for “instructions”)
fast (how fast? don’t ask)
plug-and-play

Maybe if we get enough good ones we can put them into a shoe box (or maybe an empty Xbox box) and have a ceremonial cremation at Business of Software 2007.

George Orwell once said that he – and all writers – wrote for a combination of four reasons:

1. Sheer egotism – The desire to seem clever
2. Aesthetic enthusiasm – The perception of beauty in the external world or in words and their right arrangement
3. Historical impulse – The desire to see things as they truly are
4. Political purpose – The desire to push the world in a particular direction

There are probably parallels in software development (for the first two items, definitely). If you write software, why do you do it? Post here.

Jeffrey Pfeffer can make you uncomfortable: He’ll take your preconceived notions and new-found knowledge and smash them against the rocks. He makes you think – and think again.

Pfeffer will be a featured speaker at Business of Software 2007 (www.businessofsoftware.org), October 29 and 30 in San Jose. He is the Thomas D. Dee II Professor of Organizational Behavior in the Graduate School of Business at Stanford University, and author or co-author of 12 books, including The Knowing-Doing Gap: How Smart Companies Turn Knowledge into Action; Hard Facts, Dangerous Half-Truths, and Total Nonsense: Profiting from Evidence-Based Management; and the most recent, What Were They Thinking? Unconventional Wisdom About Management . He also writes a monthly column called “The Human Factor” for Business 2.0 magazine.

Fellow Business of Software speaker Dan Nunan talked with Pfeffer recently about a wide range of management topics, from the contempt that software companies show for their customers, to the need to treat employees like adults.

Nunan: In your Business 2.0 column, you’ve written both in defense of bosses from hell, and on the value of retaining good talent. How do you determine whether or not the bosses from hell are hurting the company by chasing away good talent?

Pfeffer: I don’t think you got the point. Bosses from hell, like Steve Jobs, invariably drive talent away. And talent is inevitably important. But it’s a matter of balancing costs and benefits. All medicines, even aspirin, have side effects. So, what do you do? You balance costs and benefits. What I said in the article is that there are some fields, including software and entertainment, where the contributions of an individual creative talent may be so large that you need to put up with some personal idiosyncrasies. I never suggested that one should not try coaching or other things to reduce those personal foibles. But I just recognized that no one is perfect, and hiring and retention decisions need to balance gains and losses.

Nunan: What causes the knowledge-doing gap and how does it affect the way companies conduct business?

Pfeffer: There are numerous causes of the knowing-doing gap; among them are a climate of fear and a tendency to take what was done in the past into the future without much thought or reflection. Companies continually search for "new knowledge" and have spent a fortune on intranets and other devices for knowledge sharing. That is all well and good. But knowledge that is not turned into action – into everyday practice – isn’t worth a thing. And the research suggests that this is a big problem; that companies are not acting on the basis of what their people know.

Nunan: Can you give any examples of technology firms that have breached the gap and how have they done it?

Pfeffer: None come to mind, although I am sure there are many.

Nunan: Do you think that Alfred Sloan’s book My Years with General Motors is less relevant today than it was when it was written?

Pfeffer: It is as relevant now as it was decades ago. The basic, fundamental bases of business – for instance, Peter Drucker’s common sense insight that there is no business without a customer, so take care of your customers – and the fundamentals of human psychology have not changed. The continual search for new and trendy ideas has created more harm and havoc than anything else, although it has probably moved a lot of books and magazines.

Nunan: You’re stuck in an elevator with someone about to start a business. They bought your latest book, paid full price, and think you owe them advice. You can’t escape for a minute, so what would you tell them about starting a business?

Pfeffer: The first thing I would tell them is that buying my book doesn’t entitle them to advice. The second thing I would tell them is that they ought to ask someone who actually has experience starting a business. The third thing I would tell them I heard from one of the co-founders of SAS Institute, the largest privately owned software company in the world: "Listen to your employees, listen to your customers. Do what they tell you."

Nunan: Are managers less deluded now than they were when you started studying business?

Pfeffer: Not that I can tell. Things seem to be getting worse in some places, better in others.

Nunan: Have the management theories you elegantly lampoon in Hard Facts (such as sacking 10% of your workforce annually) ever worked?

Pfeffer: Not that I can find any evidence of.

Nunan: How would you quantify the intelligence of the great leaders that you’ve encountered?

Pfeffer: Leaders have many forms of intelligence. I think Sternberg’s research, made popular in books like Goleman’s Emotional Intelligence, is important and correct. There are many ways of assessing these other forms of intelligence, many valid and reliable measures.

Nunan: Working where you do in Silicon Valley, you must have seen your fair share of technology firms come and go over the years. Are the challenges facing the software industry any different from those in other industries?

Pfeffer: No. I think the problem in the software industry is one that many high technology and, for that matter, low technology, companies share: contempt for the customer. In what other industry do you purchase a product that is a "license" so you are forced to purchase upgrades that offer features you don’t want or need; do you get to help with the product testing; and do the vendors sell you "upgrades" that fix their mistakes?

As Walter Mossberg pointed out in a column in the Wall Street Journal years ago, if your toaster had the reliability of most software, you would throw it out. The problem now is that customers don’t trust the vendors – for good reason – so the sales cycle has gotten longer and more expensive. And the real problem is that the good companies suffer from the behavior of the less-than-good, a contagion effect that bedevils business generally and that my colleagues in leadership positions often don’t seem to pay enough attention to.

Nunan: Is this still true? Google, Yahoo, Apple, Salesforce.com, Facebook, etc., all produce software that people and businesses love, and seem to trust with incredible amounts of personal data.

Pfeffer: It may not be as bad as it once was, but it’s still true. Most of the companies you list, such as Facebook and YouTube, aren’t generating much revenue. The software industry is mostly IBM, Accenture, SAP, Oracle and Microsoft, whose revenues dwarf a lot of companies that get more ink. If you talk to people who sell business software, they will tell you they deal on a daily basis with the residue of products that don’t work and installations that are bungled.

Want an illustration? Go to Stanford’s website, go to the news archives, and type in “Oracle financials.” You will see stories in which Stanford administrators apologized to the staff for the hassle they were put through, and this for a system that cost about $50 million and won’t save the university a cent. Search out the websites that describe the PeopleSoft implementation in a university in Ohio – Cleveland State if my memory serves. The horror stories abound, and by the way, are quite current. That seems to be contempt for the customer, and is behavior that would drive companies in almost any other industry out of business.

Nunan: A big problem in the software business is the war for talent, particularly for developers. This is compounded by the very low (and shrinking) numbers of women studying computer science at university level. Given this is a problem as much for the software industry as it is for educational institutions, what should the industry do about it?

Pfeffer: That’s simple: have workplaces where women want to work. The U.S. is a laggard: the only country in the world that has no mandatory vacations or sick days – all are offered at the discretion of employers; the only country where even unpaid maternity or family leave seems to leave employers feeling that this is all just too much. I could go on. The younger generation wants flexibility and the ability to have a job and a life. Those employers that offer great places to work, in any industry, even software, don’t have a shortage of employees. Those employers who offer toxic workplaces because they mistakenly believe this is the only way to succeed deserve the employee problems they have.

Nunan: European managers are frequently told to behave more like American managers. In the tech industry, governments are encouraging the building of technology parks in the hope they can copy a little bit of Silicon Valley. Is European management really that much worse than U.S. management?

Pfeffer: I don’t know who is telling them this, but it isn’t me. A lot of people have confused economic performance (which depends on government policies such as interest rates, trade policies, etc.) with the performance of companies. Moreover, according to a detailed analysis in The Economist, European productivity growth and other measures of economic performance, including return on capital, have generally matched the U.S. – even as Europeans get more vacation and more healthcare, among other things. Europe now has a burgeoning venture capital industry and Eastern Europe is drawing a lot of investment in both technology and manufacturing.

There is no American or European management in any event. There is too much variation to speak of a dominant style. Is American management that of the companies on Fortune‘s Best Places to Work list, or is it the approach used at United Airlines?

Nunan: What do you think of the principles behind Ricardo Semler’s industrial democracy? Do we even need managers?

Pfeffer: Semler’s books aren’t followed even in Brazil, which is too bad. The evidence on the usefulness of self-managed teams is pretty compelling. We don’t need as many managers as we have, mostly because we don’t need as much control as the typical organization has. We need people to architect a culture that permits people to use their skills and abilities to make decisions. It is pretty clear that without people to protect and develop that culture, it won’t last under the pressures of investment bankers and business journalists. But beyond that, we ought to treat employees like adults.

Nunan: Why are so many managers so bad? Evidence-based management is all very well, but most managers still screw up the basics. In medicine, there are well-defined procedures for weighing up and defining what counts as evidence, but in management a lot of evidence is really just personal experience. How can managers actually get hold of quality evidence that they can trust to make decisions with?

Pfeffer: I’m not sure managers are bad. I think many companies are led by people who have more political skills than leadership skills, and I think a lot of companies are run by people who have very mistaken ideas about human motivation and the sources of company, and country, success.

The evidence is all around them. Many companies have invested fortunes in business systems that capture information but then don’t use it for decision making. To many CEOs, evidence and analysis is something for the IT department or IBM. Just as most companies don’t recognize the strategic value of their people, they don’t recognize the strategic value of better decisions based on facts, not experience or wishful thinking. But all the better for those that do it. After all, competitive advantage comes from things that not everyone is doing.

I almost got caught up in the Quechup scam that’s hitting the internet at the moment. I got an e-mail from somebody I know inviting me to join this new social networking site. Once you sign up, you have can send invites to selected contacts from your gmail / hotmail etc. contact list. However, rather than just sending invites to those you’ve selected, it will send invites to everybody in your contact list. In the case of gmail, that might be anybody you’ve ever e-mailed.

My first instinct was that this was a case of extreme incompetency. Some poor programming – a rogue semicolon that testing didn’t pick up maybe. But then I began to wonder. Rather than incompetency, could this be the most competent internet scam since the Anna Kournikova virus?

Nobody’s going to fall for the promise of pictures of naked tennis stars nowadays. But the very hint of a new social networking site and we’re falling over ourselves to hand over our login details and passwords to strangers. And it’s not fresh-faced newbies who are falling for this scam: these are seasoned web 2.0 veterans.

Brilliant.

You can find out more here:

www.businessofsoftware.org/softwareidol.aspx

You can vote for the winner at the Business of Software 2007 conference.

In response to a post on the Joel on Software forum, I’ve put together a survey about Micro ISVs. If you’re a MicroISV and are willing to (anonymously) divulge some information about sales etc. then you can fill in the survey here:

http://www.surveymonkey.com/s.aspx?sm=vzgxzT7nT_2fxaZ6_2fkALBMWQ_3d_3d

I’ll collate the responses, do some analysis, and post the results up here in a week or so. If you’ve got any comments about the survey, post them here.

It’s a human instinct to form groups. Whether it’s families, football teams, churches or schools we have an in-built urge to group together and connect with others. We are social animals: this is why social networking sites are so popular. It’s not due to technology; it’s because they fulfil a basic human need.

We do more than simply passively form groups though. We adopt symbols to identify group members. Whether it’s through clothing, anthems or jargon, we encourage the cohesion of our group and are hostile to outsiders. We over-emphasize the similarity of people within our group, and exaggerate the differences of those outside it. Blacks and whites, Catholics and Protestants, Yankees and Red Sox: there’s much more similarity between – and less within – these groups than we want to admit.

Facebook, myspace and other social networking sites let us form groups in new ways. As we group in new ways, we’ll find new ways of marking out our groups and defining them in opposition to others. Initially, this will just reflect hostility and competition in the real world. Soccer club Everton have an ‘Anti-Everton People’ facebook group (‘for all people who hate the TOFFEES throughout the world’), presumably populated by fans of rival Liverpool. Manchester United’s captain has a facebook network dedicated to him. The ‘Gary Neville is a Wanker’ network has 14,413 members and 3,115 wall posts.

As the internet makes it easy to form groups, it also makes it easy to subvert them. Anybody can pretend to be a member of your group, and harm it from within. The ‘Anti-Everton People’ group is now a closed one because of attacks from Everton defenders.

The fragility of social groups makes jargon and symbols more important. You need to distinguish those who really do belong from those just pretending. If you’re a paedophile sharing child porn then you want to be very sure that your friends are who they claim to be and not federal agents. Customs, symbols and language are one way of doing that.

As technology catches up with human behaviour, we’ll find new ways to antagonise as well as befriend. We’ll also find new ways of protecting our groups from outsiders, and to infiltrate others’ groups.

Here’s one thing that might happen. Currently, networks on Facebook are defined by individuals who have self-selected. You place yourself in the groups you think you belong to. In real life, there is another way to form groups: other people can categorise us. Sooner or later, this will happen in the virtual world too. We will have individual, private tags (an enemies list, for example). We will also be able to socially tag others. If enough people place you in a particular group, then you are tagged. If people consistently label you as ‘asshole’, ‘Manchester United supporter’ or ‘fun to be with’ then that label will stick.

Right now, words are the weapons of choice for competing social groups. But who knows what Facebook widgets, APIs and other new tools will bring. I predict a riot …

In the fourth book of Douglas Adams’s Hitchhiker’s Guide to the Galaxy trilogy, Wonko the Sane is a hermit who lives on Santa Monica beach. He has flipped the world inside out. He lives on the ‘outside’ in a small room, while the walls of his room contain the rest of the world on the ‘inside’

Why does he live there? Here’s an extract from the book:

Hold stick near centre of its length. Moisten pointed end in mouth. Insert in tooth space, blunt end next to gum. Use gentle in-out motion.

‘It seemed to me,’ said Wonko the Sane, ‘that any civilization that had so far lost its head as to include a set of detailed instructions for us in a packet of toothpicks was no longer a civilization in which I could live and stay sane.’

This is a good example of instructions at their worst. Bad instructions are superfluous, cluttering and patronising.

Instructions can be necessary though. They’re often needed to recover from bad design. Here’s the sign above the washbasins in the rest rooms of the Pitt building in Cambridge:

Doors with instructions to ‘pull’ or ‘push’, washing machines and telephones all are common examples of products whose failed design forces necessary but cluttered instructions for everyday tasks.

While we shouldn’t need written guidance on how to open doors or use taps, there are tasks we can’t reasonably expect to work out from first principles or by trial and error. In these cases, we need written instructions.

Designers often avoid text almost pathologically, but written instructions are a good way of communicating complex, conditional and interdependent tasks. A sentence can be worth a thousand pictures, as you’ll appreciate if you’ve ever tried to build Ikea furniture.

At their best, instructions are simple, elegant and built in to the design. They’re not glued prominently on as an afterthought or tucked away somewhere that nobody can find them.

Making porridge is a good example of an infrequent task that requires instructions:

This is an excellent example of good instructions. They’re where you need them: directly on the packet so they can’t be separated from the porridge. They’re clear, well laid out and tell you what you need to know. Also, note the ‘pour milk to here’ mark. The instructions could just have said ‘add 180ml of milk to your bowl’ but a bit of thinking and good design means that the instructions go beyond telling you what to do; they actually help you do it.

So how does this translate into software? First, don’t include instructions just because you can. Every extra word is clutter: if you don’t need it, cut it out. Second, instructions are sometimes a work-around for bad design. This happens, but clearly it’s a last resort. Third, good instructions are often part of the product. Rather than simply telling you what to do, they help you do it or even do it for you.

Ever since James F Moore’s 1993 article in the Harvard Business Review it’s been fashionable to talk about business ecosystems. A good example is the Microsoft ecosystem. Microsoft is the shark and third party tools are the pilot fish that eat Microsoft’s leftovers.

This analogy is wrong. Microsoft isn’t the shark – it’s a greedy fisherman. With one hand it throws bread crumbs to encourage the little fishes to grow while with the other it trawls the bottom of the ocean for fish large enough to eat. It catches the fish, but its nets scrape the ocean floor bare, ruining the ecosystem for decades to come.

Microsoft have abandoned their benign tending of the ecosystem. They have moved from helping it flourish to harvesting it. You can see this in many areas. In the developer tools market, rather than providing a set of core development tools they’ve decided to try to flog us bug tracking, source control, unit testing, load testing, enterprise modelling and collaboration suites. These were markets already well served by good, affordable third party tools. For the sake of a few thousand dollars per seat off enterprise customers too lazy or scared to investigate the other possibilities, Microsoft have shut down that part of the ecosystem.

In SQL Server, Microsoft are open about this, at least in private. Senior people in the SQL Server team have always made it clear to me that they want to put everything any SQL developer or DBA could ever want in the box. This will inevitably shut down the SQL Server ecosystem too.

Red Gate – the company I work for – is in a better situation than most. We’ve been going a while, we’re profitable, our revenues are growing and the people who work here are outstanding. Microsoft’s intentions, however, are clear: they want to own the entire SQL Server ecosystem. Anybody left standing in 5 years time will be there despite Microsoft’s efforts, not because of them. Although some companies – Red Gate among them – will survive the cull, many won’t. I do not envy the fragile companies in this market.

Microsoft’s actions are as futile as they are frustrating. They will trawl with their nets, destroy the ecosystem but reap little for themselves. Business intelligence, gaming, mobile phones, business accounting, CRM, development tools and SQL Server third party tools are all areas where Microsoft are now competing with their one-time partners. Judging by their current efforts, Microsoft will not win in many -if any – of the areas they are competing in.

The ecosystem won’t be destroyed overnight: it will wither slowly. Third parties will start to leave the ecosystem and they won’t be replaced. When entering new markets, companies will think about joining the Microsoft ecosystem and then won’t. By the time Microsoft realise what is happening it will be too late.

There’s no truth to the rumor that there are bracelets circulating around Silicon Valley inscribed with WWGD (What Would Guy Do), but it’s not inconceivable. Guy Kawasaki has an uncanny knack of being at the right place at the right time with the right strategy. He describes it as “Guy’s Golden Touch: Whatever is Gold, Guy Touches.”

Considering the traffic on his “How to Change the World” blog, and the success of his Truemors site, a lot of people are hoping the Guy Touch rubs off on them.

Guy will be a featured speaker at Business of Software 2007, October 29-30 in San Jose (www.businessofsoftware.org). He was kind enough to answer some questions from Business of Software on the current VC environment, evangelism, and what he would do if he was on the Microsoft board.

BoS: You write and speak extensively about innovation. Where are you seeing innovation today in the software industry?

Kawasaki: Most of the innovation is happening with "two guys/gals in a garage" creating web sites with MySQL, Ruby, and other open-source tools.

BoS: Where is the software industry in most need of innovation?

Kawasaki: Innovation is needed everywhere you look. It’s just that some places look like they’re already "owned" by large companies. That’s a fallacy.

BoS: You’re a VC. If two guys/gals in a garage came to you and said they wanted to create a new search engine, would you fund them if they were persuasive enough?

Kawasaki: Based on the Google phenomenon, we’d certainly take a look at it, but it would be an uphill battle because there’s already Google. Of course, there was already Yahoo! and Inktomi when Google was starting. This is the conundrum of venture capital: You never know.

BoS: What attributes are you looking for in terms of technology and management for companies you fund?

Kawasaki: I look for unproven people in unproven markets with unproven business models because this is where I think the big hits occur. However, I’ve yet to prove this theory.

BoS: You set up Truemors for $12,000. Presumably you have people telling you similar stories and asking for millions in return. How has your experience with Truemors changed your behavior as a VC?

Kawasaki: I certainly know now what can be done in two months with $12,000. If an entrepreneur tells me that he or she needs $1 million, five engineers, and a year to build a social networking or user-generated content site, I will throw them out.

BoS: Would you have funded Truemors?

Kawasaki: No. It didn’t need enough capital, and the CEO has a dubious amount of management experience.

BoS: Are we in a bubble?

Kawasaki: You bet we are. Isn’t life great?

BoS: So why are you still investing?

Kawasaki: Because hope springs eternal and because venture capital firms are not set up to short private companies. Just because we’re in a bubble doesn’t mean that every company will fail.

BoS: You are perhaps the world’s best-known evangelist for your work at Apple. Is evangelism still effective?

Kawasaki: More so than ever because more companies are starting with smaller, if not non-existent, marketing and advertising budgets. When you have $20 million to introduce a product, you seldom rely on evangelism.

BoS: You often make fun of Windows in your speeches. But Apple still isn’t one of the top 5 PC manufacturers in the world, and you won’t see many IPhones replacing the Blackberry on Wall Street. You’ve already worked at Apple (twice), so suppose you were on the board of Microsoft sitting on your 90%+ market share. What would you do?

Kawasaki: I would be wondering whether I should buy a house in Montana or the south of France –or maybe both. Or which Gulfstream would look best in my hangar. And why the company whose board I sit on can’t seem to hire designers despite the infinite money it has.

When was the last time you went to a conference and really learned something? At Business of Software 2007 you’ll learn the timeless, eternal truths of what drives success in the software business. No fads, no sales pitches, no bull.

The early bird discount for Business of Software 2007 will end on August 15th. To hear Guy Kawasaki, Joel Spolsky, Tim Lister, Eric Sink and more great speakers for the special 2-day price of only $1195 you need to book soon.