ON “AGILE MODELING”

From: Ben Stevens

Date: 11 Oct 2004

I had not known the term "agile modeling" until I read your article Agility Derives From, Is Not Substitute for Foundation Knowledge, but I have definitely encountered the practice before. In fact, I once had to give up a database project because I was not "agile" enough. (The database was for tech support, but Marketing people kept wanting to add technically irrelevant data for demographic purposes. They also kept insisting that I change attribute names that sounded "too negative", such as "complaint". I couldn't keep changing the database and front-end application fast enough for their ever-changing tastes.)

I agree with the point of your article, and have nothing to say about it. Instead, I would like to question the value of agile modeling itself. Let me start by repeating a quote by Ambler:

The first version of the KSMS [agile model] supports the critical functions required to run the dojo: the management of basic student data and collection of money from them. When you look at the “Initial Data Model,” you see that we’re not tracking the student’s state/province. Because we’re building for a single dojo that isn’t near the border, we can safely assume that all students live in the same province. Lesson number one: Agile data models are just barely good enough. Agile developers solve today’s problem today and trust that they can solve tomorrow’s problem tomorrow; therefore, if we need to support people living in another province, we’ll add that functionality at a later date … Don’t build something until it’s needed.

I don't know anything about the dojo or where it is, but I do know that I live in an area where some people travel hundreds of miles on a daily basis, crossing into other states, so I'm already conceptually bothered by the example Ambler gives. Even allowing for his reasoning, the moment that a state attribute does get added, someone has to go about updating all the students who were in the database from before. This kind of massive update is an invitation to anomalies.

Furthermore, let's take the same approach with a different attribute. Let's say that the dojo doesn't have an e-mail account, so they don't bother storing students' e-mail addresses. Later, the dojo does get an account, and intends to use it often. At that point, somebody has to go to the trouble of asking all the students for their e-mail addresses in addition to the trouble of adding the data. This is tedious and error-prone.

Another mind-boggling aspect of agile modeling is how "agile" application developers must also be to keep up with a changing database schema.

As someone who has numerous online accounts, I see the effects of such schema updates all the time, and I am annoyed when a service I have been using for a long time suddenly refuses to work for me until I add new data that they only now require.

So, it seems to me that agile modeling is dangerous to data integrity, tedious for data collectors (in cases where they are used), difficult for DBAs and programmers, and annoying for users. I see nothing good in it. Sure, sometimes attributes need to be added to a database. But why should anyone make a habit of purposely leaving out attributes until they absolutely need them, whenever that need might arise? What happened to analyzing one's goals and thinking ahead a little bit?

Lastly, perhaps I'm too judgmental, but I think that anyone who jumps on board with willy-nilly "agile modeling" probably does not have the mentality to learn and properly use the relational model. Put another way, although agility and foundation knowledge are not at odds themselves, the more a person favors agility (as I have seen it), the less likely it is that the person has foundation knowledge.

Ed. Comment: Ambler does not seem to know or understand data and relational fundamentals, which does not stop him from criticizing them to the point of absurdity, for example On Logical Persistence Models, or Weekly Quotes of 2002 (10/06, 12/01), and 2004 (6/11).

Revised 4/28/06

Posted 11/12/04