Just turned up at OT2004. Fellow attendees with blogs that I know of:
Lisp is the Burgess Shale of computation. Full of unusual byways of software evolution that never quite made the mainstream but were just as valid as the winners.
Duncan McGregor accidentally observed that
Plans rarely survive contact with the Customer (after von Moltke, German Chief of Staff, World War I)
Last week Tim Mackinnon, Nat Pryce, Joe Walnes and I pulled out all the stops to get a paper written in time for OOPSLA. The only way we could make it was to work overnight on Friday and we finally sent it in at about 5:00 Saturday morning (CyberChair runs on Samoan time, so a Friday deadline is about 11:00 on Saturday in London).
The moral of the tale? We were all pretty dazed the following week (well, in my case, more dazed than usual). Just like Financial Debt and Technical Debt, Physical Debt is useful when you need to borrow against the future, but it has to be paid off — and quickly. That's why XP includes Sustainable Pace.
Sometimes you need to break the rules to remind yourself why they're there.
As Martin says, some people like tools that force the issue, so you can't do Bad Things or ignore failures, and some people like tools that make new concepts possible. Then he says,
You might think that all restrictions on what a developer does imply a directing attitude, but it's not that simple. As an example, consider memory management. You can think of this as a directing feature: programmers can't be trusted to manage memory correctly so take away their ability to allocate memory. But I look at memory management as an enabling technology - it takes away something I don't want to worry about, so I can concentrate better on those things I do care about.
Which, to me, maps nicely to Ward's view on problems.
A friend of mine once said that there are problems and there are difficulties. A problem is something you savor. You say, "Well that's an interesting problem. Let me think about that problem a while." You enjoy thinking about it, because when you find the solution to the problem, it's enlightening.
And then there are difficulties. Computers are famous for difficulties. A difficulty is just a blockage from progress. You have to try a lot of things. When you finally find what works, it doesn't tell you a thing. It won't be the same tomorrow. Getting the computer to work is so often dealing with difficulties.
To me, memory management is a difficulty. A fiddly task to perform because we don't after all have infinite RAM. It once took me three weeks to chase a memory smash in a (very well written) runtime library I was working with. Do I miss it? Hell, no. I think the same case could even be made for static typing. A good type system, such as the one I trained on, should help to focus your code and make it more expressive.
Roy Disney speaking to Disney Shareholders on 3rd March 2004 and quoted here
shows that he understands the reality of inellectual work. I've worked at too many places that feel like this, and too few that don't.
Unfortunately, our corporate values have been compromised in recent years.
In large part, this is the result of a cynical management's belief that, in the absence of ideas, the road to success is to cut back on everyone and everything that once made you successful, that you don't really need to give your guests value for money, that creativity and originality are luxuries you can no longer afford ... that art and artists are commodities to be bought and sold like any other office supply.
To me, the wrong-headedness of these beliefs is self-evident.
The creative process is the lifeblood of the Disney Company. If it is to thrive, we must do everything possible to establish an environment in which it can once again flourish.
Creativity is a funny thing -- difficult to quantify, but obvious when it's missing. It's a living, breathing force with a life of its own, and it tends to flower among individuals or small groups. It doesn't always show up on demand ... or at convenient times or places. And it often gets killed by committees or by something called strategic planning. So we need to always be on the lookout for ways to nurture it, and not let it be trampled by a lowest-common-denominator mentality
In this interview with Bertrand Meyer on Artima, Bertrand Meyer hopes that Test-Driven Development is like Design By Contract. Well, yes and no.
Meyer has the good grace to admit he hasn't really had time to look into TDD, but his view is that:
I haven't had the opportunity to talk to, for example, Kent Beck about this, but I hope he would agree that the right form of test-driven development is where the tests are systematic. And the best way I know to derive a systematic test is from contracts, because they're much more general and abstract. You can derive the specific from the general. You cannot really infer the general from the specific.
First, he has the usual misunderstanding of TDD being about testing, not unreasonable given its name. But "extracting the general from the specific" is exactly what the refactoring part of TDD does, that's how you remove duplication. The flip from Design as a Process of Invention, to Design as a Process of Discovery takes a little while to get used to but it's liberating. It puts an end to the "deer in the headlights" experience where there are just too many unknowns to make the next (binding) decision so you find yourself incapable of deciding anything.
There's another, more interesting, discussion that I think is worth having with the Design By Contract community. One of the important experiences of TDD is that you can control the scope of the code by adding and removing individual tests. You can slice and dice functionality and it's easy to understand. Contract specifications tend to be harder to manipulate that way because they describe general properties — that's the whole point. I have a suspicion that this is just a matter of style, but it's not how DbC people see things. Like Prof Meyer, I haven't had these discussions with the right people either (so that makes us even?), but it would be entertaining to find out.