Fixed-Price Options

I have to put a link up. This is a great collection of diverse opinions from Agile leaders on how to do Fixed-Price Agile projects. Many I've already seen before, but not all, and never collected in one place.

I may need several copies of this one.

One more book I want to buy for all my managers.

Alistair Cockburn has hit a home run with this one. Crystal Clear nails the essential whys and hows of Agile.

Of course, I've only read two chapters so far.

Chapter 9 is the one page summary that ties it all together, and if you're familiar with the concepts it really can all be said in one sentence. As he says, it's a little bit Zen. I love it.

Chapter 1 introduces things a little slower via a fictional but convincing e-mail dialogue. Cockburn neither hides nor exaggerates the complexity. He focuses on the properties of a successful team instead of the processes. The goal is to find the smallest methodology which works.

This is a very angry man.

CausticTech is quite entertaining. He seems to insult everybody equally. I'm not sure what he actually does like, but he's still entertaining...

If you can stand a spot of bad language, misspellings, and no capitalization unless he's SHOUTING, he's got some interesting rants that I tend to agree with. I just don't get quite so upset about it.

Data-Only-Objects and the Command Pattern

I've been considering some intriguing new architecture options. The architecture I'm contemplating relates to Windows applications working with relational databases. That's the style of app I usually work on.

First, some of the influences:

I've used Microsoft's DataSets. These bring a subset of the relational data into memory and work with it in a standard relational form. Very effective, but very relational.

I've been heavily influenced by Evans' DDD book on Domain-Driven Design, which very well encapsulates the database. Repositories control and hide access to the persistent storage. There's also other good things about this, but this part is relevant: Objects are unaware of persistence.

Relentless Feedback

I ducked out of work today a few minutes early to make it to LouisvilleAgile, a users’ group of the Agile Alliance. This is a recently started group started by U of L professor Ted Strickland to discuss Agile Methodologies. It's an interesting collection of people. They got my name because I had previously signed up at the Agile Alliance site.

For now I'll just say that LouisvilleAgile seems to be making good progress forming a local community with a diverse group of coders, managers, and academics. I'll talk more about the local group another time.

Domain-Driven Design

This is one of the most important books I read in 2004. Evans has done a lot of thinking about how to represent the ever-shifting realities of business in code. This is great stuff.

It starts with a simple idea: define a Ubiquitous Language that the entire team, both customers and developers use. This is a great way of keeping communication clear.

And, the interesting thing is, without ever once calling attention to it, Evans makes use of a Ubiquitous Language to help explain the rest of his modelling concepts. He explains how he models Entities and Value Objects, which I will come back to in a second. He uses different fonts and an immediate visual contrast to explain his Ubiquitous Language.

Object-Oriented Databases for EVERYBODY

DB4O went open source last month. Probably a good strategy. They're still likely to be much more expensive than any relational database for apps you want to distribute into the wild, but in-house development and students tinkering with it are quite free.

I was once quite enamored of object-oriented databases. This has waned slightly as I've learned workarounds for using object-oriented languages with relational databases. But I still look forward to spending some time trying it out.

I think two months ago I would have been even more excited, but the Domain-Driven Design (full review probably coming) book has some really good ideas on abstracting away the database. By distinguishing between Entities (first-class identifiable business objects) and Value Objects (immutable values, like strings), and providing a Repository (to manage each Entity's data access), I'm honestly not sure it'll look that much different if I were to roll an app over to OODBMSs.

Waltzing with Bears

DeMarco & Lister have done a very nice job on this. I picked up Waltzing with Bears after I heard it recommended at a local agile user's group meeting. It got my attention early with an anecdote about an 1876 paper presented to the membership of London's Metaphysical Society. The paper was William Clifford's The Ethics of Belief.

Partial solution for version control

TortoiseSVN is a GUI front-end for the new Subversion system, and it solves at least one of the problems I had with Subversion. It’s not perfect, but it’s good.

I can right-click on the folder containing a project, tell it to Commit, and it can, in a single step, remove the files I deleted, store the files I added, and commit changes for the files I changed. Just what I wanted. All I have to do is check a little box telling it to look for files that weren’t in the system already, and hit OK once or twice.

Effortless Version Control

Why is version control so difficult?

This has been bugging me more and more since I read the Pragmatic Programmers' trio of wonderful books on Automation, Version Control, and Unit Testing.

They're all very well written books. The two that Hunt & Thomas did themselves is definitely a notch better than the Project Automation one, but only by a hair. I have no complaint with these books.

My complaint is with the whole bloody version control "industry", if you can call it that. CVS, Subversion, MKS, SS, and probably PVCS & others, too.

I think we're focusing on the wrong things. It makes sense to do so, too, because each new system is an evolution on what came before. But I think it's time for a bolder step. Not that I have time to take that step, but I can get off my chest what I think is required.