Design

Philosophy

Good design flows from imagination. Imagination, in turn, is fed by stories.

So, I will start this page with a quick look at some of the best books I've read in the last year.

Software

Robert Glass' book is a wonderfully contrarian look at the software development process. The format is similar to the Summa Theologica in that each chapter consists of articles that follow a set format. The article begins with a short statement, such as:

Maintenance is a solution, not a problem.

This is followed by a discussion section wherein he lays out an argument to support the statement, e.g.:

Maintenance is software's unique solution to the problem "we built this thing, but now we wish we had built something a little different."

Next comes a mostly shorter section in which he examines why his original statement of fact is controversial. Mostly, I agreed with Glass; occasionally, I would find myself agreeing with the critics of his position. Either way, I did always appreciate seeing another side to the issue. It is the rare author who will devote this much space to presenting opposing views.

The final two sections, Sources and References, are necessary for completeness but would have been so much more useful had they been live links rather than book citations.

Joel Spolsky is never a boring author. He is well known for his ability to inject humor into the driest of software subjects. Now he has proven that he is not the only talented software writer out there.

While most of the articles he has included in this collection are available for free, it is still a worthwhile purchase (used copies are now quite cheap). I still prefer good, old fashioned paper books sometimes. If nothing else, it pulls one away from the screen for a time. Not having to skip over links or ignore ads removes distractions that can short circuit useful contemplation on what you've just read.

Management

There is no end of management advice books out there. Each presents the author's opinion on how to best approach the delicate task of organizing people to work together. Of necessity, those opinions have been formed by the author's own experience. The authors of this book, however, have the distinct advantage of drawing on the results of two huge, in-depth studies undertaken by the Gallup Organization. The first surveyed over a million employees from a broad range of companies, industries and countries.

Our research yielded many discoveries, but the most powerful was this: Talented employees need great managers. The talented employee may join a company because of its charismatic leaders, its generous benefits, and its world-class training programs, but how long that employee stays and how productive he is while he is there is determined by his relationship with his immediate supervisor.

The second study collected and analyzed 80,000 one-and-a-half hour interviews with managers in over 400 companies to discover what the greatest of those managers had in common.

Their ideas are plain and direct, but they are not necessarily simple to implement. Conventional wisdom is conventional for a reason: It is easier. It is easier to believe that each employee possesses unlimited potential. It is easier to imagine that the best way to help an employee is by fixing his weaknesses. It is easier to treat everyone the same and so avoid charges of favoritism. Conventional wisdom is comfortingly, seductively easy.

The revolutionary wisdom of great managers isn't. Their path is much more exacting. It demands discipline, focus, trust, and, perhaps most important, a willingness to individualize.

To describe what Ricardo Semler did to his father's company as "breaking all the rules of business" or "defying conventional wisdom" does not fully to capture the radically transformative nature of the changes he made. This book, which was the all-time best-selling nonfiction book in his native Brazil, describes how he changed a traditional business into a highly decentralized, highly democratized, highly unusual and highly successful organization.

To survive in modern times, a company must have an organizational structure that accepts change as its basic premise, lets tribal customs thrive, and fosters a power that is derived from respect, not rules. In other words, the successful companies will be the ones that put quality of life first. Do this and the rest – quality of product, productivity of workers, profits for all – will follow. At Semco we did away with strictures that dictate the “hows” and created fertile soil for differences. We gave people an opportunity to test, question, and disagree. We let them determine their own futures. We let them come and go as they wanted, work at home if they wished, set their own salaries, choose their own bosses. We let them change their minds and ours, prove us wrong when we are wrong, make us humbler. Such a system relishes change, which is the only antidote to the corporate brainwashing that has consigned giant businesses with brilliant pasts to uncertain futures.

Geometry

"How Round Is Your Circle?" is an engaging combination of history, mathematics and model-making. I originally purchased the book in order to understand the answer to the title question. However, I found the most interesting section to be the authors' account of the development of a mechanism for creating motion in a straight line. James Watt created the first approximation in 1784 with a very simple and ingenious linkage that produced nearly straight motion over a certain range of operation. Other inventors followed with improvements, but it was 80 years before a French army officer finally devised a perfect solution to the problem.

The mathematics behind each solution is explained clearly and comprehensibly. The chapter is, in effect, a mathematical history of the development of a simple-looking, but vitally important, piece of technology. It is a reminder that the most important solutions are often the simplest - and the simplest solutions are often the hardest to find.

Eberly's book is certainly not a page-turner. The mathematics are dense and the code-snippets are correspondingly complex. What it lacks in charm, it makes up for with an abundance of useful information. I used it primarily as an explanation of the mathematical justification for the code in his WildMagic library.

Non-Fiction

A first-hand account of aerial warfare in World War I might seem out of place in the company of books on software design and management techniques. What it does have in common with the other books here is that it is a beautifully written and captivating account of how men use technology - in this case, early aeroplanes:

I turned south toward Boulogne, climbing, always climbing. Already I was two miles above the earth, a tiny speck in the vast rotunda of the evening sky. The sun was sinking solemnly in a black Atlantic cloud-belt. To the east, night crept up: a lofty shade drawn steadily over the warring earth.

Technology has its dark side, of course. This is never more evident than during war. Lewis' description of watching a gas attack from the sky above is particularly chilling:

In the light westerly wind it slid slowly down the German trenches, creeping pantherlike over the scarred earth, curling into dugouts, coiling and uncoiling at the wind's whim.

In 1917, he was posted to a test squadron and flew all the latest models straight from the factory. His descriptions of his tests put me in mind of some of the software testing I have seen over the years.

The design of aircraft was a very much more fluky business than it is today. Every new machine was an experiment, obsolete in the eyes of the designer before it was completed, so feverishly and rapidly did knowledge progress.

Gladwell describes Blink as a book about...

... rapid cognition, about the kind of thinking that happens in a blink of an eye. When you meet someone for the first time, or walk into a house you are thinking of buying, or read the first few sentences of a book, your mind takes about two seconds to jump to a series of conclusions. Well, "Blink" is a book about those two seconds, because I think those instant conclusions that we reach are really powerful and really important and, occasionally, really good.

I bought this book after watching Gladwell's TED talk, "What we can learn from spaghetti sauce". It presents the work of various researchers interspersed with stories of how complex, highly structured decision making schemes often fare poorly when compared to snap judgements made by experts in a particular field. Each one of us is an expert in something - if only our own like and dislikes. Given enough experience, our unconscious mind is capable of making highly sophisticated judgements without the necessity of having each logical step, or each relevant data point, rise into our consciousness. In effect we each develop a metal library, or framework, of functions that we can call upon to save us the trouble of explicitly re-coding the solution to problems we've already handled.

Agile Software Development

Tools are important things - but they are not everything. Tools get used by people. Software development tools get used by groups of people working together to produce a common project. How should they use those tools so as to ensure a successful outcome?

If software projects routinely went as expected and produced mostly satisfactory results, this would not be a very interesting question. Of course, software projects are notoriously prone to failure - either total, unmitigated disaster or the more frequent simple cost and schedule overrun. Companies that experience software development failure (that is, nearly every company that has been involved in software development for any significant length of time) are eager to find ways to avoid repeating the experience.

"Process" became a big buzzword in the 1990's. Both managers and developers realized that something had to be done. But what?

Experts were consulted, teams were formed, books were written and process facilitators were hired to answer that question. As with many of life's thornier issues, achieving agreement that a problem existed was relatively easy; getting everyone to agree upon the best solution was not. Many of the proposed solutions made good Dilbert-fodder but appeared to result in little lasting benefit in return for their costs: extensive training sessions, soporific documents and lots of uncomfortable hoops through which luckless managers and developers were forced to jump.

Unfortunately, the problem will not go away. So whatever the shortcomings of any proposed solution, it is usually better to have some process than none at all. Communism was a terrible solution to the age-old problem of how to structure a just civil society, but even those who suffered under it in the old Soviet Union generally saw it as preferable to the anarchy that directly preceded, and briefly followed, the establishment of the Soviet state.

Of course "Communism is better than anarchy!" does not logically lead to "Let all become communists!" There are much better systems on offer. The realm of software development, though, is still barely half a century old. The answer to the question, "Which software development process is the best?" has yet to be conclusively determined.

The most promising current contender is agile software development. The solutions it recommends are a radical departure from the received wisdom and are still relatively new. In general, upper management has been slower to recognize the benefits of agile processes than software developers have. Recently, there has been more movement on this front as the success of agile methodologies has become more wildly known. Last year, IBM - long seen as the epitome of a large, ponderous corporation - announced that it was officially adopting agile methodologies.

Perhaps the most controversial and initially counter-intuitive part of Agile to many people is pair programming. Writing code has traditionally been viewed as an almost strictly solitary pursuit. However I have always found that human interaction, rather than impeding the creative process, actually accelerates it. Everyone who has been stuck on a seemingly intractable problem has had the experience, at some time or other, of solving that problem while in the midst of explaining it to a colleague.

Agile software development is not without its critics. Some dismiss it out-of-hand as a fad, but others have taken the time to express more detailed reservations. Wherever the truth may lie, agile development is here to stay - and that's a good thing.

Ruby

After spending more than a decade perfecting my C and C++ skills, I was ready for a change. I'd done some development using Java and various forms of Basic but the advantages of these languages over C++ always struck me as too minor to make for much excitement. So when I decided it was time to teach my children how to program, I first looked at some alternative languages.

Perl, Python and PHP caught my attention. PHP was simple enough but was too closely tied to server-side scripting. I wanted to start them on a more general-purpose language. Perl is certainly more general purpose, but although I learned it quickly and I've used it profitably, it is simply too cryptic to foist upon a beginner. Python looked more promising but before I could get deeply into it, something wonderful happened. I discovered Ruby.

Ruby is simply a beautiful language. Developed in Japan, it combines powerful features with a spare, minimalist syntax. Everything in Ruby is an object. Integers are objects; classes are objects; blocks of code are objects. Blocks of code, in fact, are one of Ruby's neatest features. They work similarly to C function pointers but are much more flexible and easy to use.

The best way to learn more about Ruby is to start with the book Programming Ruby. This is the only programming book that has ever had me Oooh-ing and Aaah-ing while I was reading it. If all you want is a quick, fun and free introduction to the language, nothing can even remotely compare to A Quick (and Hopefully Painless) Ride Through Ruby (with Cartoon Foxes)

Web Design

When I started seriously looking at web design back in 2002, after many years of system programming, I was not pleased by what I found. I had spent the previous decade writing software that primarily interfaced with hardware or other software. For every program of even modest size I also provided a human interface which allowed a user (often, but not always, myself) to control and monitor that program's operation. As for my code itself, I'd always taken pride in writing code that looked good - neatly formatted, modular, well-commented and with a clear separation between data and code.

HTML encourages none of this. Almost every page I examined looked messy, contained repetitious elements and was comment-free. This last I could understand since download time is a major factor in the usability of a page. The other problems were less excusable. Surely someone must have devised a solution to fix this. To my great relief, I found that someone had.

CSS

Cascading style sheets(CSS) were that solution. They allow the appearance of a page to be separated from its content. As single CSS file can define the style for an entire site. Font size, background color and many other details can be changed in one central location - no more repetitive tags.

Even more interestingly, CSS positioning properties can replace tables as the primary layout mechanism. Not only does this eliminate another set of repetitive tags and centralize even more information, it also breaks the elements on a page free from the restrictive confines of a very inflexible layout system.