Steve Johnson of Pragmatic Marketing (www.pragmaticmarketing.com) won the closely contested Software Idol competition at Business of Software 2007.  Johnson’s presentation centered on a market-driven model for managing and marketing technology software.

Congrats to Steve and the other finalists: Geoff Perlman of Real Software; Bob Walsh of 47hats.com; Jeffrey Gordon, author of the Software Licensing Handbook; and Jerry Foster of Plexus Systems.

Bob Cramblitt reports on Eric Sink’s talk from Business of Software 2007. To sign up for the BoS 2008, visit www.businessofsoftware.org

Why did the marketing guy cross the road?  To avoid the geek approaching him.  Or vice versa.

Why would any company want to have geeks involved in marketing?  Or, conversely, why would any geek want to be involved with the marketing wonks, or “clueless weinees” as Erik Sink called them in his Business of Software 2007 presentation.

Sink, the author of the Apress book The Business of Software, says that developers are often involved in marketing whether they know it or not.  If they are involved in deciding what features to build, they are doing marketing.

Geeks have three problems with the marketing role, according to Sink:
(1) Generally, they suck at marketing, but then again, everyone does.
(2) They tend not to be too normal in discriminating between good ideas and bad ideas.
(3) They fall in love with technology for technology’s sake.

Still, having geeks involved in marketing is generally a big plus for both the company and its developers.  The company gets the unique perspective of technical staff, and developers get to play a greater role in the fate of the products they produce.

Bob Cramblitt reports on Bill Buxton’s talk from Business of Software 2007. To sign up for the BoS 2008, visit www.businessofsoftware.org

Software product development is broken, and Bill Buxton is angry.  Addressing the current process turns Buxton into a raging, slightly profane comedian with a very serious agenda.

Buxton, a principal researcher at Microsoft Research, said today at the Business of Software 2007 conference that the industry is based almost entirely on N+1 products.  In its history, according to Buxton, Adobe has created just two new products in house: Acrobat and Illustrator.

The problem is that new software projects are greenlighted from day 1, before the company really knows what it is going to build, if it can be built, and how it is going to be sold. Rarely is there participation from all the important elements within the company: technical, marketing and creative.

Buxton likens the typical approach of software engineers having sole responsibility for new product development to an ice hockey team with all goalies.  No matter how good your goalies are, they aren’t going to beat even a bad team with the proper mix of players.

The Buxton approach centers on the power of sketching user experiences at the beginning of the product development period.  Sketching is quick, timely, inexpensive, disposable, and plentiful. 

There is an ambiguity in sketching: If you want to get the most out of a sketch, you need to leave big enough holes – like Swiss cheese.  There has to be enough room for the imagination.  The goal is not arriving at a design, but the best design.

One of the overriding lessons from Buxton is this: Everything is best for something, and worst for something else.  The participation of people from multiple disciplines, combined with the experimental flexibility of sketching, can determine whether a product will fly before critical resources are committed.

Bob Cramblitt reports on Tim Lister’s talk from Business of Software 2007. To sign up for the BoS 2008, visit www.businessofsoftware.org

“Tim Lister is an anthropologist,” says Simon Galbraith, co-CEO of Red Gate Software. It’s an apt description. Lister uncovers the often-hidden patterns that constitute software culture, everything from the developers’ war against perceived inferiors (i.e. marketing wonks) within the company, to the smell of dead fish that permeates a project that’s doomed from the beginning.

More than 70 patterns are outlined in the upcoming book, Project Patterns: From Adrenaline Junkies to Template Zombies, co-authored by Lister. Here are some of the ones he discussed in his Business of Software 2007 presentation:

• Mañana – the loss of a natural sense of urgency. Agile development fights mañana.
• The dead fish of failure – projects that are dead from the start. Everyone smells it right away, but they hunker down and work.
• Lessons unlearned – Retrospectives rarely trigger change.
• What smell? – People in the organization cannot detect its underlying vitality or decay.
• Marilyn Munster – Like the normal girl among the monsters in the old TV family, the esteem often given technical workers versus managerial staff varies. In some organizations, developers are king; in others they are pawns.
• Surprise! – The manager offering rewards and incentives gets responses in addition to those he planned.
• Everyone wears clothes for a reason – Complete openness grinds progress to a halt.
• Music – people with real musical skills are disproportionably represented, sometimes extremely so, in technology organizations.

Lister’s essential message: Look for patterns, name them, then propagate or defeat them.

For more, check out the Tim Lister interview on this blog:

http://blog.businessofsoftware.org/2007/07/from-project-sl.html

Bob Cramblitt reports on Guy Kawasaki’s talk from Business of Software 2007. To sign up for the BoS 2008, visit www.businessofsoftware.org

Guy Kawasaki was part of the Mac team at Apple between 1983 and 1987, which he called “the largest collection of egomaniacs until Google.” He’s had huge successes, and made some mistakes, including not taking a job in the early days of Yahoo.

Kawasaki kicked off Business of Software 2007 with 11 key points for fulfilling “The Art of Innovation”:

1. Make meaning – Decide how you are going to make meaning. Nike makes meaning out of shoes.
2. Make mantra – Put together 2 or 3 words that explain why your software exists. Most companies have mission statements, not mantras. Some proposed mantras from Guy: Wendy’s: “Healthy fast food.” Nike: “Authentic athletic performance.” FedEx: “Peace of mind.” eBay: “Democratize commerce.”
3. Jump to the next curve – Don’t go for 10% better, shoot for 10X better: Mac vs. Apple II; telephone vs. telegraph. No ice harvester became an ice factory and no ice factory became a refrigerator company.
4. Role the DICEE – Deep: PhotoShop. Intelligent: Someone anticipating what I need to do. Complete: Create a totality of experience. Elegant: Nano controls thousands of songs with a wheel. Emotive – Harley-Davidson.
5. Don’t worry, be crappy – Version 1 means never having to say you’re sorry. Shoot then test. A first product can have elements of crappiness.
6. Polarize people – The Scion xB isn’t for everyone. The more people you try to serve, the greater the mediocrity.
7. Let a hundred flowers blossom (Mao) – If you ship software and find users are not the right people (the audience you anticipated), “take the money.” Ask people who are buying why they are buying
8. Churn, baby, churn – The first permutation of the next curve will have elements of crappiness, but you have to move beyond crappiness quickly. Need to fix your revolution. Can’t stay crappy forever.
9. Niche thyself – Provide a unique product or service that delivers value to the customer. Examples: Fandango movie reservations – no standing in line. Breitling Emergency wristwatch – antenna sends out emergency signal. Smart Car – park perpendicular to curb. Trek Lime – automatic transmission in a bike. LG Kimchi refrigerator. Royal Caribbean – ice skating rink on a cruise ship.
10. Follow the 10/20/30 rule of pitching: Maximum of 10 slides in PowerPoint for 60 minutes. Complete presentation in 20 minutes. Use 30 point font size. Dark background; sans serif font; fill or left justify.
11. Don’t let the bozos grind you down – Bozos don’t have vision. Examples: Ken Olsen of DEC saying that people didn’t need computers at home. Kawasaki’s response to Yahoo: “It’s too far to drive and I don’t see how it can be a business.”

Yeah, the Red Sox had a great line-up for the World Series (maybe we should start calling it the "American Series"?), but check out this one for today’s Business of Software 2007 conference, listed by order of appearance.

Guy Kawasaki
Tim Lister
Bill Buxton
Software Idol winners
Eric Sink
Breakout sessions (take your dilemmas to the experts)
Alberto Savoia
Joel Spolsky

Stay tuned for highlights throughout the day.

Stay tuned tomorrow for ongoing, almost real-time posts from the 1st annual Business of Software conference.  Wish you were here.

The idea for the Business of Software conference first popped into my head in March this year. We’ve now got 2 weeks to go until the conference starts. This is the second business I’ve started (I also co-founded Red Gate Software). Although the businesses are clearly very different, there are some interesting parallels. Here are some lessons I’ve relearned:

Having a good product isn’t enough
Even if you have an excellent product, you can’t just drop it into the marketplace and expect people to find it, and buy it. If you build a better mousetrap, the world will not beat a path to your door. Of course, you can’t market a dog: a good product is necessary, but not sufficient. Whatever your product – whether it’s software or a conference – you need to spend a lot of time, thought, effort and, less importantly, money on getting people to notice it.

Try twenty small things; not one big thing
If you don’t know what you’re doing, you can never tell what’s going to work and what’s not. Rather than intellectualising a lot, selecting the single best way of doing things, and then doing it, it’s best just to get out there and try things. Some things will work, some things will fail, but slowly you’ll start to turn the flywheel. We tried many things to market the conference: print ads, Google ads, web ads, asking speakers to publicise the conference, sofware giveaways, a free ebook, blog articles, themed fortune cookies and speaker interviews. In the end, the most successful bit of marketing was when Joel Spolsky mentioned an advert we’d run in San Jose airport. There’s no way we could have predicted that: we tried enough and eventually we got lucky.

Listen to other people
Getting other people’s perspectives, and their advice, is always useful. I’m fortunate enough to have had advice – and help – from some great people.

Ignore other people
Many people – often the same people – will tell you that what you want to do can’t be done; it’s a dumb idea; it will never work. Listen to them, but do it anyway.

Minimize the downside
Minimizing the downside is as important as maximizing the upside: only risk as deep as your pockets go. For the conference, that meant guaranteeing the minimum number of hotel rooms I could, even though that limited the potential upside. For Red Gate, it meant only spending the money we had, and carrying on contracting for my previous job for the first 6 months after start-up.

Maximize the downside
Although you don’t want to bankrupt yourself, your pride is less valuable. Putting yourself in a position where failure means humiliation, or embarrassment at least, is a powerful motivator. With Red Gate, running it as a Micro ISV for an hour or two a day in parallel with the day job would have been easy. If I failed, nobody would notice, and my world would have continued much as before. By quitting the day job and publicly announcing my intentions to friends, family and colleagues I removed the easy exit.

At some point, you need to take the plunge. You’re never going to have enough evidence or data to predict that what you’re going to do is going to work. Think about it, but then just do it. For the conference, that point came when we had about 30 attendees. The speakers were asking if the conference was going ahead and others were questioning its viability. Backing down and cancelling would have been easy. It was scary, but I decided to go ahead, knowing that there was a good chance that I wouldn’t get enough sign-ups, that the conference would flop, and that I’d make a tit of myself. Paradoxically, increasing the chance of looking like an idiot on failure actually decreased the overall chance of looking like an idiot.

I’ll be expanding on some of these points in more depth over the next couple of weeks, and I’ll add some more lessons learned once the conference is over. I hope to see you in San Jose.

Enjoyed this post? Subscribe to our RSS feed or subscribe by e-mail

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.