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

Everybody in the capacity audience at Business of Software 2007 wanted to know what he thought about employee hiring and retention.  He is Joel Spolsky, CEO of Fog Creek Software and author of the popular Joel on Software blog.  In a fast-paced presentation and question-and-answer period, Spolsky covered what type of people his company looks for, how he attracts them, and how they are kept in the fold.

The Fog Creek screening process for incoming resumes includes the following factors:

• Passion – This is manifested by long-time interest in programming and an agressive pursuit of goals.
• English – Not mastery of the English language, but good communication skills.
• Creativity – As evidenced by whether applicants have shown that they want this particular job at this particular company.
• Selectivity – The candidate has been selected by good schools and/or employers.
• Brains – As reflected by good grades, participation in math camps, and special honors.
• Diversity – People unlike those currently in the company; people with different ideas, and ethnic, cultural backgrounds.

Those who make the resume cut go through a phone interview, then could be invited to NYC for a personal interview, with all expenses paid.  Spolsky says it is important to make a good impression on the prospective employee.  The most important factors for most applicants are working with smart and interesting people, working on interesting problems, free lunches and other benefits, a nice office, and a boss who "gets" them.  Way down on the list is salary, although that certainly has to be competitive.

Two key criteria outweigh all for Fog Creek (1) being smart and (2) getting things done. An optional third factor: not being an asshole.

Things that Spolsky and his team have done to help make Fog Creek a great place to work include:

• private offices
• nice computing systems with large monitors
• Aeron chairs
• giving employees what they need to do their jobs
• free lunches
• more vacation than the average company
• high bonuses

Brand awareness has become a major factor not just for products, but for attracting recruits, and the prominence of the Joel on Software blog definitely helps.  Spolsky says he has been on campus recruiting trips and heard Fog Creek mentioned in the same breath as Google and Microsoft.

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

Alberto Savoia of Agitar Software (www.agitar.com) knows crappy software, in every permutation.  More than talking about it, his company is eradicating crappy software through better testing.  Business of Software 2007 attendees were treated to a hilarious treatise on crappy software from Savoia.  Those who experienced Alberto live won’t forget him anytime soon.  For the rest of you, there’s the interview on this blog: http://blog.businessofsoftware.org/2007/09/alberto-savoia-.html

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.