The secret to creating 'pretty' code

Christopher Seiwald, chief technology officer for Perforce Software, thinks code should be more than just functional — it should be pretty too.

Seiwald's approach aims to encourage software developers to build concise and efficient code that avoids programming verbosity and untidiness. He has authored a white paper, Seven Pillars of Pretty Code, that deals with these issues, as well as the wider themes of software change. That white paper was included in a book from O'Reilly called Beautiful Code.

Considerably smaller in size than its nearest competitors, Perforce has insisted that its position in the market is defined by its core competency in version control. Despite the fact that vendors such as Serena Software and IBM offer arguably broader products that feature change management as part and parcel of wider application lifecycle-management solutions, Perforce has managed to carve itself a niche and attract customers including computer games developer Electronic Arts.

ZDNet.co.uk caught up with Seiwald in London this week to discuss his thoughts on how to guarantee high-quality, bug-free code and why "software change and configuration management" should form a fundamental element of all software-development projects.

Q: For those readers not familiar with the principles of software configuration management (SCM), can you give us the elevator pitch to put it in perspective?
A: Essentially, SCM is all about managing the changes that software developers make to their applications as they develop them.

Modern-day application development scenarios may feature hundreds of individual developers all inputting to one centralised repository of data that typically has a complex structure, with overlapping layers. Keeping track of what has been done at every stage of the project is essential if it is to stand a reasonable chance of success.

A defect-tracking component is also needed, and we do offer one, but we also support the other popular defect trackers out there.

How do you react to criticism that SCM is merely a branding term used to describe a generic packaged software-management process?
Well, SCMis a broad term that means different things to different people. We focus on a fairly specific aspect of software development; our expertise is in version control.

Perhaps SCM is an unfortunate term for something so fundamental to the process of software development. Look at what developers do every day; they are focused on their integrated development environment [IDE] and the build-edit-test processes needed to drive code generation. IDEs are typically not version-control aware, so there is a need for a management layer to provide a holistic view of the project.

I don't see IDEs taking over the version-control market as, in practice, they are too busy orchestrating other tasks within the total build.

How do you differentiate yourself from your competitors and what makes SCM different from application lifecycle management or IBM's Rational approach to management of dynamic software projects?
IBM's ClearCase compares directly with our technology and they have a bunch of technology that sits on top of that which goes to build the argument for yet another acronym — ALM, or application lifecycle management.

We play our part well and our customers are happy to build their process on top of our engine. ALM tries to do a lot more, but doesn't often meet the customers' needs and the version-control element is often weaker as a result.

Looking at rapid application-development environments that feature continuous builds, SCM becomes an imperative as more and more code goes into the data repository. This way, when the system goes wrong, it's possible to go back through the version-control system and see who broke the build.

What do you say to people who argue that checking and testing procedures already encompass what you are selling as a standalone packaged product?
Anyone involved in software development knows that code isn't "done" until it has been checked into the repository. Back in my early days we simply called this "process" and, quite simply, it is how things are done.

That said, this "process" has yet to be nailed down, despite the fact that version control as a methodology has been around for 25 years or so now. We're not there yet, and testing and debugging, however thorough, is not a standalone cure-all for clean code production.

What development environments are typically well suited to SCM?
If we think about how SCM works in a wider sense, it has a role to play in the management of a variety of scenarios. For example, it can be used to keep track of and manage web content, digital assets, such as graphics for games development, and computer-aided design. Chip manufacturers are even using it for — and please excuse another acronym — EDA, or electronic design automation, in the production of chipsets and integrated circuits.

As more and more software now needs to spawn variants, so that it can be used on different devices or different platforms, recoding becomes much more efficient if SCM is used to track where and when reusable application components can be identified.

You are known for your Seven Pillars of Pretty Code theory. What do you think is the most important pillar to keep in mind for developers on the quest towards "beautiful code"?
Well, it's hard to pick one, as I think they are all somewhat intertwined. I'm fond of the blending theory, which says that code changes should blend in with the original style. It should not be possible to discern previous changes to a file without seeing the previous revisions, as nothing obscures essential visual cues more than a shift in style.

It's kind of related, but I also urge developers to break code into logical blocks within functions and disentangle the purpose of those separate blocks so that each does a single thing or single kind of thing. I guess a lot of it is about planning your "process" before you start programming.

As chief technology officer, what aspects of SCM do you see developing most radically in the next five years?
When we started out, it was all about speed and time to execute the SCM process and a lot of our branding still carries the "fast SCM" message. But computing power has massively escalated in recent years, so I think now we're extremely focused on the role of SCM in large multinational organisations.

With so much outsourcing and offshoring to accommodate into the equation, sheer size and scaling the version-control process to a new level for global enterprises is what will make or break the next phase of this technology's existence.