Paddling Upstream

Another shiver ripped violently through Coco. She stood on the dock, facing a huge dilemma: whether to get into the canoe or not. Only minutes before, she had been tied to a tree as we drifted silently across the lake, away from her. Our departure provoking loud yelps of displeasure and frantic barking.

We had tried to get her into the canoe, but she refused. Possibly she didn't like the noise of the water pounding up against the side of the canoe, or maybe it was just the idea of sitting there and not being allowed to move that made her fear it. Whatever fears it was that were motivating her, she was clearly in turmoil.

We returned to the dock to pick her up. She seemed to get the choice: either we head off again with her or without her, it was that simple.

Poor Coco, but you have to see it from my perspective. My wife and I have gone to the cottage for a week off. There is a lake close by where we can canoe. We were looking forward to cruising around the lake and it was a beautiful day for it. However, Coco is afraid to go beyond her comfort zone. She is normally a strong dog -- the adventurous type -- but something about the canoe just wasn't clicking. The three of us had been out a bit earlier, but we had to turn back because Coco kept trying to jump out of the canoe; threating in the process to tip our little boat over.

We figured we'd leave her behind, tied to a tree, but that didn't work either. Her furious yelps of distress were echoing across the lake. It sounded like someone was beating the dog. It was embarrassing. We returned to pick her up, but now instead of jumping into the canoe, she is having the doggie equivalent of a hissy fit.

As usual for a cottage trip I brought along a number of books to read. One of them, "The Pragmatic Programmer" by Andrew Hunt and David Thomas, has been on my must-read list for years. I've read bits and pieces, but I've never sat down to read it cover to cover.

It is a great book -- one that I wish I had written -- full of understanding and good advice, but sometimes I find the programmer culture leaking through too much. One such section that struck me as particularly odd was:

"Finally, there is the straightjack effect. A design that leaves the coder no room for interpretation robs the programming effort of any skill and art. Some would say this is for the best, but they're wrong. Often, it is only during coding that certain options become apparent."

Mainstream programming culture is all about freedom. And that means giving every programmer the right to make major decisions in the project. Realistically that can't be a good thing; too much freedom is always chaos. It is no wonder than, that so many projects implode by the hands of their own coders.

There are a multitude ways of doing anything, particularly with a computer, but consistency is critical towards manging complexity. Leaving too many degrees of freedom until the last moment for some coder to respond to it 'instinctively' is a bad idea. You cannot build a big project if you cannot control how it is built.

The results of the position advocated in the book -- more freedom for the programmers -- is a common problem often found in software. Dig in a bit deeply into many GUI interfaces and suddenly the paradigm changes. The interface feels different and obeys different conventions.

Freedom to design at the last moment means a lack of overall consistency. Whether it be a library interface or a full graphical one. In a small program the inconsistencies might not be noticeable, but they can be quite sever and debilitating in a large one.

Ironically, programmers don't really need room for interpretation.

The Pragamatic Programmer's view of development is closely aligned with the lightweight methodology and Agile programming movement. As such, a foundation of the development strategy, and alluded to in the book as "Tracer Bullets", is to build in a highly iterative approach. Small sets of development. Using that and refactoring, if a programmer discovers a better option for implementation, they could do the original design first and then enhance it in the next iteration, thus keeping the whole project on a determinable schedule.

If the design role and programming role are separated, then a post implementation discussion would set the stage for implementing better technology in the next phase. So long as there weren't professional jealousies involved. And with truly iterative development, the phases are short enough so there is little time to wait before the work actually gets into operation.

Developers would do better to stick to the original design, but use their understanding of its flaws to guide enhancements. In this way, brilliant inspirations of programming don't become islands of isolated code. The system -- the whole system -- should obtain a reasonable measure of consistency.

Another book I was reading at the cottage was called "Under the Banner of Heaven" by Jon Krakauer, the author of "Into Thin Air". This book was about Mormon fundamentalists and how they related back to the Mormon faith. Another good book, although it can be a bit preachy at times.

Strangely enough, it got me thinking about mainstream Computer Science, and what might be considered to be on the outskirts of the mainstream.

The mainstream for software seems split these days between those that are advocating a lighter Agile approach to development and those that are following some variation on the traditional heavyweight stance. While the lightweight side is more visible on the web, the heavyweight approach appears to be more popular with the actual software producing organizations. Both sides tend towards the same cultural bias of allowing individual programmers a significant leeway in what they build; although the heavyweight side tries not to admit it.

Whenever you drift away from the masses, you run the danger of being labeled a fundamentalist. The term seems to mean a desire to go back to the fundamentals, before the problems began, but it also implies a fanatical stance. For religion there will always be someone wanting to return to the golden years. For software, I think we are still waiting for the golden years to start, which makes being a fundamentalist a bit more challenging. You can't return to something that doesn't exist yet. Punch cards or assembler were hardly golden, and debugging dangling pointers ate huge amounts of time for C programmers.

Still the problems with software development, when they are not ignored or dismissed, may have changed a bit but have not really improved. There is just more code out there because the industry has been around a lot longer. The use of brute force is still the most popular way of belting out computer instructions. It is still about endlessly stuffing straw into one side of a bag, while it is leaking out the other side. The technologies look better, but are less reliable.

I think it could be easier if we just made it easier, and it would be more successful if we stopped shooting ourselves in the foot all of the time. Many -- but not all -- problems with software development are self inflicted because of our determination to stay with our specific development culture. The key in the quote was "... robs the effort ... of any skill and art".

The mainstream, it seems, wants what Paul Graham is advocating in "Hackers and Painters" to be true. That programming is an intensely creative discipline, much like painting. That we need freedom of expression to truly rise to great heights of development. That unlike construction, inconsistencies don't matter particularly if they are inspired. We are not bound by the physical world, so why do we need to be consistent?

A funny sort of approach given that programmers are no less annoyed by ugly inconsistencies, than their users are. Ranting about frustrations with a big company's messy interface is common practice. It is only when it is our own personal inconsistencies that we think it is acceptable.

I suspect that this will change. I think in time, as Computer Science matures, it will look for more rational and concrete approaches to programming. It will ask for more assurances that the right code is being developed, and it will move alway from all of the snake-oil salesmanship about getting the documentation correct or the wishful thinking that maybe we can skip a design all together and just code merrily along all day.

The mainstream will bend away from personal freedoms towards being more successful.

Programmers will eventually move out of their comfort zones and accept a somewhat lessor degree of freedom during implementation. They have to, if they want to build bigger and more complex systems. But in exchange, they will get an enhanced job satisfaction and less stress from impending failures.

We, as craftsmen want to build really sophisticated systems, but our own culture and methodologies have become the gravity that binds our hands. Until you can accept a measure less in control, you cannot effectively combine your skills with others. That defines the limits of your abilities. That defines the limits of the project. That defines the limits of the industry. Cross beyond those limits and the obvious happens.

Eventually Coco succumbed. She stood up, then collapsed in an exaggerated moan. Crying and pacing, and almost pleading for us not to go canoing. But she realized that we 'would' go without her.

First one paw, then gingerly another; finally the whole dog was seated in the center of the canoe.

We shoved off from dock, and made our way for a nice leisurely trip around the lake. It was a warm sunny day, with a light breeze. That fresh scent of lake water and evergreen trees was permeating the air. What could be better for a canoe ride?

After several minutes, Coco calmed down, and after a few more I think she actually started to enjoy the ride. At least she wasn't left behind, terrified to break out of her comfort zone. For all her fussing, fears and hysteria it turned out that canoing about the lake just wasn't such a big deal after all. If only I'd know how to explain this to her in the beginning.