CACM_TACCESS_one-third_page_vertical:Layout 1  6/9/09  1:04 PM  Page 1

ACM Transactions on Accessible Computing

◆◆◆◆◆

This quarterly publication is a quarterly journal that publishes refereed articles addressing issues of computing as it impacts the lives of people with disabilities. The journal will be of particular interest to SIGACCESS members and delegrates to its affiliated conference (i.e., ASSETS), as well as other international accessibility conferences.

◆◆◆◆◆
www.acm.org/taccess
www.acm.org/subscribe
if all the
components of a
software system
are too inter-
dependent, then
a change to one
can result in
an injury to all.

odic builds. I won’t get into periodic testing, which can save even more time and money, because if your build is always broken, you clearly have not achieved a sufficient level of sophistication to move on to nightly tests.

Even though the broken code will still get into the system, with a periodic build system the offending person will find out fairly quickly that he or she broke the build and hopefully will admit it in an email message (“I broke the build, hang on a second)” and then repair the error. While this is still suboptimal, it is far better than what you had before.

Sometimes it is the build system itself that is the source of the problem. Many modern build systems depend heavily on caching derived objects, as well as the parallelization of the build process. While a parallel build process can provide you results more quickly, it can often lead to build failures that are false positives. Trying to build an object that requires another object to be created first, such as an automatically created include file, always leads to trouble. Maintaining the list of dependencies by hand is an error-prone, but often necessary, process. If you are using a build system that depends on caching and uses parallel builds, then your problems may lie here.

Now we come to the final area that is the cause of build problems. The way in which a piece of software is put together, frequently referred to as its architecture, often impacts not only how the software performs when it runs, but also how it is built. I hesi-

tate to use the word architecture since overuse of the term has led to the unfortunate proliferation of the job title software architect, which is far too often a misnomer.

If all the components of a software system are too interdependent, then a change to one can result in an injury to all. A lack of sufficient modulariza-tion is often a problem when software ships, but it is definitely a problem when the software is being compiled. When a change to an include file in one area leads to the build breaking in another area, then your software is probably too heavily interlinked, and the team should look at breaking the pieces apart. Often such links come from careless reuse of some part of the system. Careless reuse is when you look at a large abstraction and think, “Oh, I really want this version of method X,” where X is a small part of the overall abstraction, and then you wind up making your code depend not just on the small part you want, but on all of the parts that X is associated with. If you get to the point where you know it’s neither carelessness nor poor infrastructure that is leading to frequent build failures, then it’s time to look at the software architecture.

Now you know the three most basic ways to alleviate frequent build breakage: shaming your teammates, adding some basic infrastructure, and finally improving the software architecture. That ought to keep you out of jail, for now.

KV

Related articles on queue.acm.org

Kode Vicious: Facing the Strain http://queue.acm.org/detail.cfm?id=1160442

Making Sense of Revision-Control Systems

Bryan O’Sullivan

http://queue.acm.org/detail.cfm?id=1595636

A Conversation with Steve Bourne,

Eric Allman, and Bryan Cantrill

http://queue.acm.org/detail.cfm?id=1454460

George V. Neville-Neil ( [e-mail]) is the proprietor of Neville-Neil Consulting and a member of the ACM Queue editorial board. He works on networking and operating systems code for fun and profit, teaches courses on various programming-related subjects, and encourages your comments, quips, and code snips pertaining to his Communications column.