Beautiful Software

128 Great Road, Bedford, MA, 01730


Complex Software Is Just Too Complicated! (and How to Save Yours with the 1-5-10 Rule of Software Design), February 2012. Many software projects collapse under the weight of their own complexity. Why does this happen again and again, to competent organizations? The problem is that many of the world’s large software projects are just too darn complicated. This article introduces a new guideline for software design to help you avoid a familiar fate. Click here to read.

FBI Sentinel Is In Trouble, January 2012. The FBI is trying, once again, to modernize its case file system. The previous effort, Virtual Case File, failed in 2005 at a cost of $170 million. The latest project, Sentinel, is costing $450 million and has already slipped more than two years. Sentinel is in trouble. Click here to read.

Why Bad Things Happen To Big Software Projects, January 2012. Examines the special nature of very large, important software projects. Points out that many of these projects are designed for failure from the start, and offers new approaches so the projects are designed for success. Click here to read.

Beautiful Software (book), Amazon link, April 2011.

Why Software Really Fails, And What to Do About It. Dr. Dobbs, March 2010. It is not news that software projects fail more often than other kinds of engineering. But why? In this essay, I maintain the reason is we don’t understand the true nature of software. Software is a machine, but we don’t apply standard well-known machine design principles to our software projects. Click here to read.

Hey Programmers! We Got No Theory! Dr. Dobbs, March 2010. There has been considerable interest lately in advancing software engineering from a fad-driven discipline to something founded more firmly on an underlying theory. This article serves as an introduction to the problem, and points to the larger initiative at Click here to read.

Podcast about Software Engineering vs. Computer Science., November 2009. An interview on the popular software engineering podcast about my recent article on this topic. Click here to listen.

The Missing Theory of Refactoring. Dr. Dobbs, October 2009. Refactoring is a powerful method for improving the design of software, but there have always been some open questions about this helpful method: When should software be refactored? Which refactoring transformation is appropriate in a given situation? Why does refactoring improve design? This article answers these questions, by supplying an overall theoretical framework for refactoring. As a good theory should, the framework suggests new refactorings for areas of software design not yet addressed. Click here to read.

Is Software Patentable?, June 2009. I weigh in on the debate about whether software is inherently patentable, and argue that of course it is. Click here to read.

Software Engineering ≠ Computer Science. Dr. Dobb's Journal, June 2009. Software engineering is different, in a frustrating way, from other disciplines of computer science, such as computability and complexity. It is harder to define concepts in software engineering and harder to prove results. This essay proposes an explanation for these problems, and shows what kinds of progress can be made. Click here to read.

A Software Schedule Ain't Nothin' But a Piece of Paper., March 2008. A somewhat humorous look at software schedules, real and imaginary, with practical tips to avoid software project crises. Click here to read.

All Source Code Should Be Open. on 8/26/02. A provocative essay which argues software quality would be improved worldwide if every software product included a copy of its source code. The article generated a lot of discussion on LinuxToday. I then wrote a follow-up piece (11/26/02) based on the discussion and reader feedback. The follow-up was linked by Slashdot and generated even more lively discussion. Here is the original article, and the follow-up piece.

A Quagmire in the Tar Pit. on 5/13/02. This article looks at the dilemma faced by software managers given the current proliferation of software development methods, including CMM, ISO-9000, Extreme Programming, and Rapid Development. Each requires a large investment of time and effort to learn and implement, so which one should an organization commit to? Is one best for all uses? Are any worthwhile? Click here to read.

It's Not About Lines of Code. on 3/11/02 and Slashdot on 3/18/02. What makes a programmer highly productive? Is it lines of code per day? Lines of good code? In this article, I examine the concept of software productivity. I look at some of the standard definitions for productivity and show why they are wrong. I then propose a new definition that captures what programming really is about. Click here to read.

Are There Limits to Software Estimation?, on 1/7/02 and Slashdot on 1/11/02. This article responds to a paper by J.P. Lewis and explores questions about our underlying ability to estimate the development effort for software projects. The article explains results from complexity theory and information theory and shows how these apply (and don't apply) to software estimation. Click here to read.

Most Software Stinks! Slashdot on 9/4/01 and on 9/7/01. Discusses the current state of software design and concludes that much of it is poor. Proposes a set of guidelines for creating higher quality software by following the lead of beautiful physical buildings. Click here to read.  (This article generated over 700 comments on the Slashdot discussion board. Here is a reply to some of the comments that I wrote for

Why Software Engineering is Not B.S. Dr Dobb's Journal, April 18, 2001. Examines the status of software engineering within the field of computer science. Argues that software engineering's low standing is not justified and explains why it should be taken more seriously. Click here to read.

Open Source Projects Manage Themselves? Dream On. Lotus Developer Network, Sept 12, 2000. Challenges one of the central tenets of Eric Raymond's essay The Cathedral and th Bazaar, that open source projects are self-managing. This article was linked by Slashdot, LinuxToday, NewsForge and many other sites. Click here to read. (Eric Raymond replied to the article above here. I replied to Eric here.)

What the Linux Community Needs to Grok. LinuxToday and Slashdot, February 14 and 15, 2000. Describes the angry reaction of some Linux fans to previous articles I wrote and the lessons I learned from this. Outlines four fundamental ideas that the Linux community should "grok" (understand deeply) if is to be adopted widely. Click here to read. (The article above generated over 500 comments on the Slashdot discussion board. I replied to those comments here. The reply generated another 200 comments.)

A Software Trend Worth Its Buzz. Boston Globe, February 15, 2000. Provides an overview of the Capability Maturity (CMM) for software project management and considers whether its use should be expanded. Click here to read.

Healing Sick Software Projects. Boston Business Journal, November 12, 1999. Describes how to rescue a software project that is in trouble. Discusses the common reasons software projects go awry and what to do about each one. Click here to read.

Creating Poetry In Software. Boston Globe, July 6, 1999. Draws a parallel between the design of buildings and the design of software. Shows that creating software which is "beautiful" leads to software that is better by objective measures as well. Click here to read.

Improve Your Company's Ability to Estimate Software-Development Cycles. Datamation, April 1999. Argues that software engineers should have greater input to project schedules, and presents specific methods for doing so. Click here to read.

Developing Software On Time. Boston Globe, March 2, 1999. Compares software development to construction of a new house, and shows that software can be finished on schedule, just as most buildings are. Click here to read.

Reviews for Beautiful Software book...

"This is a very enjoyable and informative series of essays exploring many aspects of software development that deserve more attention. Connell's main theme is that we tolerate substandard development practices in software that we would never tolerate in other fields."

"Highly recommended for anyone who appreciates good design in general and finds fault with computer systems and their software in particular."