Programming on Bulrush Labs — Richard Tibbetts

Proactive Assumption Violation: Avoiding Bugs By Behaving Badly

Sun, 14 Nov 2010 23:38:00 +0000

Bugs are a fact of life in software, and probably always will be. Some bugs are probably unavoidable, but a lot of bugs can be avoided through good architecture, defensive programming, immutability, and other techniques. One major source of bugs, especially frustrating bugs, is non-deterministic behavior. Every programmer has experienced bugs which don’t reproduce, which require a special environment, or special timing, or even just luck to make happen. To avoid these bugs, programmers learn to favor determinism, making sure their software behaves the same way every time.

Algorithms for the 21st Century

Thu, 28 Sep 2006 22:51:00 +0000

Went to a talk at MIT tonight, by Stephen C Johnson, a researcher at The Mathworks. The talk was sponsored by the Greater Boston ACM. The paper, Algorithms for the 21st Century, was presented at Usenix 2006. The general thrust was how computer architecture has drifted from the idealized model used in most algorithms classes, in significant ways. The major focus was on the memory subsystem, and how caching can effect algorithmic performance. By looking at the behavior of very simple algorithms, we can see fairly complex variations in performance, by factors as high as 60 times worse. This in turn implies that the performance of complex algorithms will be even more diffi
cult to characterize.
One big take-away is that the built-in cache management schemes of modern memory systems are pessimal for certain algorithms. This actually sounds quite a bit like the complaints against operating system disk buffer/virtual memory management by database authors. Database algorithms, because they often have large storage access requirements that can be characterized in advance, benefit from managing their own buffers. Similarly, it seems like scientific computing (eg, Matlab), which wants to manipulate gigabytes of memory in very structured ways, would benefit from direct management of caching. Of course, cache management needs to run at processor-speed, unlike disk buffer management, so writing heavyweight algorithms is inappropriate. Unfortunately, the talk did not discuss any recommendations for extentions to enable management. I wonder if something as simple as being able to mark a page as no-cache in the TLB would be sufficient.
My other take-away is that computer science researchers don’t understand computers nearly enough. The presenter, while familiar with processor design and memory architecture, wasn’t really able to explain the behavior of these simple algorithms in their entirety. I’m always bothered when I encounter this lack of understanding. On some level it seems that it should be possible to fully understand computer systems. After all, they are developed by humans, and to a first approximation their behavior is deterministic and well defined. Unfortunately, they change rapidly, and so any abstract models we develop are shortly invalidated. Fundamentally, this is what makes computer science difficult.

Steve Vinoski on Extreme Programming at Iona

Fri, 25 Aug 2006 21:06:00 +0000

Thursday at StreamBase we had a lunch talk by Steve Vinoski, Chief Engineer at Iona Software. Our CEO (Barry Morris) is former CEO of Iona, and he asked Steve to talk to use about Extreme Programming (XP). Iona switched to the extreme programming model nearly 10 years ago, and was the first large product company to change over. Their experiences were documented in a paper by Jim Watson.
At StreamBase we use several agile development techniques, but are not faithful to any one methodology. I expected the talk to be about how being faithful to XP was a great thing for Iona. From my reading, I understood that XP demanded total fidelity in order to succeed. Every one of their twelve points is supposed to be critically interdependent and synergistic.
What I learned from Vinoski was that drinking the koolaid is not required. Iona worked directly with Kent Beck, originator of XP. Apparently in person he is a lot more laid back than in his writing. For example, Iona didn’t find pair programming particularly worthwhile, and ended up giving their engineers back their private spaces. They never implemented a 40 hour work week. They do test first programming, but not religiously. They try to fit development into 2 week iterations, but again are not strictly attatched to it. For example, documentation work generally lags behind development, and frequently their iterations don’t actually result in customer-visible functionality.
The other thing I found interesting was that Iona was another example of a pattern I see in extreme programming success stories. At Iona, engineering was a mess before they switched to XP. They didn’t have nightly builds, good testing, or a consistent view of the source tree. Releases were made in an ad-hoc manner, and there was little or no visibilty or feedback in the engineering process. With the introduction of XP they were able to get many of these issues under control. Like many XP stories, things started out really bad. With the introduction of XP they got much better. I can see two plausible explanations for the frequency of this story. It may be that only companies in a lot of pain are able to marshall the resources to change to XP, and so only troubled companies try it. But it may also be that XP is only worth attempting if your organization is on the rocks. Otherwise, moving to a more moderated agile process may be the way to go.
At StreamBase we use many agile techniques. We benefit greatly from automated testing, and have good test coverage. We use a branch driven development model, and keep trunk in a shippable state. We break projects into small milestones (a few weeks, and we keep making them smaller) so that development can be visible. We keep developers as close to customers as possible. And we remain introspective, looking for other opportunities to improve on our process. Many innovations in software engineering come under the banner of agile development today. I think any engineering organization can benefit from learning more about extreme programming and other agile methologies. But I think taking a moderate approach is prudent, unless your organization is in a great deal of pain.