Summary
Software development involves constantly making return on investment decisions. Investing extra time to achieve higher quality software can yield dividends far into the future, or can cause you to miss a market window in the near term. How do you make the tradeoff between software quality and development speed?

The first few years of trying to build a community site at Artima.com, I wrote some of the worst code of my career. It is nowhere near the worst code I've seen, but it is among the worst I've written. Why? One reason is that among all the software jobs I've had, I've felt the most intense pressure to get software done quickly at Artima. I knew I was hacking, but I felt that the right tradeoff was to get the functionality out the door as soon as possible, even at the expense of code quality. Part of the pressure came from the fact that at previous jobs, I was pretty much just a programmer, though sometimes also a project manager. But at Artima, I've had many more hats to wear, so my programming time has been limited. Nevertheless, much of the pressure came from perceived competitive threats. I perceived that I needed to hit certain market windows before they vanished, and that made me feel a lot of pressure to move fast.

Looking back, I think hacking was the right decision. Most of the quality of service problems I've troubled my users with have little to do with the hacks I did. The hacked software worked quite well enough to meet the business need. Getting features out the door fast allowed me to build up the audience, and getting real feedback from them has taught me a great deal about the business domain of online publishing and communities. Now I have several years of real experience to draw from, and I'm to a great extent starting over with the software. I now have a much clearer picture of what I want to build and how I want to build it.

A few months ago, Frank Sommers and I started work on what we're calling the "next generation" of Artima. This time around, I'm trying hard to ensure our software is well-designed and crafted. The reason is that at this juncture, I want to build an architecture that will enable us to scale our business. I perceive a long-term return on investment for taking great care in how we shape that architecture.

I find that I am usually quite capable of producing good enough software by hacking. (By hacking, I mean cutting quality corners, such as hastily copying and pasting code.) The trouble with hacking is not that the code you hack together isn't good enough to meet the immediate need. Rather, the trouble is that long term the technique doesn't scale. As you hack together more and more pieces, eventually the whole thing wants to fall over. You have to make extra efforts to prop it up so it doesn't fall over, and that slows you down. By contrast, taking the time to build a solid architecture up front slows you down initially, but can help you move much faster later.

I'm currently making the bet that, so long as we don't completely miss the market windows, putting in place a solid architecture will give us a competitive edge that could have a big payback in the future. But I'm nervous, because I know of competitors who are working in the same directions. And they may be hacking. For the time being, though, I'm trying to keep a steady hand on the wheel as we take the longer, higher quality route.

How do you decide when to cut corners, and when not? Looking back, how often did you regret not moving faster with more of a hack? How often did you regret that you didn't move slower and do higher-quality work? And most importantly, how have you successfully achieved quality software at a fast pace in the past? What I'd really like to do is generate high quality software as fast as any hack. Have you been able to do that? How did you accomplish it?

Talk Back!

Have an opinion? Readers have already posted 59 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Bill Venners adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Bill Venners is president of Artima, Inc., publisher of Artima Developer (www.artima.com). He is author of the book, Inside the Java Virtual Machine, a programmer-oriented survey of the Java platform's architecture and internals. His popular columns in JavaWorld magazine covered Java internals, object-oriented design, and Jini. Active in the Jini Community since its inception, Bill led the Jini Community's ServiceUI project, whose ServiceUI API became the de facto standard way to associate user interfaces to Jini services. Bill is also the lead developer and designer of ScalaTest, an open source testing tool for Scala and Java developers, and coauthor with Martin Odersky and Lex Spoon of the book, Programming in Scala.