Antipattern: Forms Over DB

Any experienced business software developer knows that CRUD makes the world go round. For those who don’t know, that stands for Create, Read, Update, Delete. It’s the bread and butter of many business apps, the transactional ones that exist to, essentially, manage business data. Oodles and oodles of apps exist to do just this, and that’s it.

It’s fine, in and of itself, because it works, as a bare minimum. It’s also fairly boring to code,as a developer. It gets tiring writing the same code over and over and over again. So, these smart folks who get bored with basic CRUD start inventing ways to make their jobs more interesting.

What this looks like are things like auto-generating CRUD forms “scaffolding” from a database. It looks like ORM–object-relational mapping, where the objects are similarly generated from a DB. And all sorts of variations on these themes.

The problem is that in an effort to not get bored, to not “waste time” with boilerplate code, these solutions miss the mark. The intelligence and creativity of these highly skilled individuals is being squandered. The essential problem lies in the requirements themselves.

When you conceive of software as, essentially, a portal to edit database records, the potential of that software is immediately and fundamentally warped and diminished. It presumes an antiquated interaction model, one in which the database is some angry pagan deity. The people must bring their offerings of information, feed it to the all powerful database, hoping that at some later point, they can return and request some meager insight from the oracle (pun intended).

It is an immensely impoverished and impoverishing view of how software can help people do business. We need to move beyond these primitive interaction models. We need to understand the flow of business activities–from a human perspective. Instead of looking for points in a business process into which we can inject these artificial, software/database-oriented data offerings and petitions, how can we make software feel like it is part of what people are trying to accomplish? Their goals are most assuredly not to create, read, update, and delete records in a database. Their goals are to achieve some human end, and they put up with CRUD type interactions as a means to an end.

The closest thing I’ve seen in the dev side of things to a more human-oriented design was SOA. At least it attempted to frame the design in terms of what people were trying to accomplish. Domain driven design also heads in the right direction, and to some extent, so does “object thinking” that tries to focus more on behaviors and less on data and properties.

But a more robust approach to understanding and formulating a high quality software design is one that follows one of the many UX/Design approaches. There are many, many resources out there for devs and BAs to learn how to improve their design process and “learn UX”; I myself have written much along these lines and given many presentations. I tried to distill this into practicable principles recently in my UX for Devs Manifesto. My company has released a currently free interaction design tool that any dev or BA should be able toque kilt pick up and leverage in an improved design process.

There’s no good reason for us to be continuing with the Forms Over DB antipattern today. In addition to warping software design from the get go, it also leads to other “efficiencies” like auto-generated validation with its inscrutable error messages and subpar input interactions. The good news is that there is a better way, both to get to a better result and to offer a more interesting, more intellectually challenging software design problems that keep us from getting bored and wasting those energies on ways to more efficiently create poor user experiences. Further, we are more empowered today than ever to craft awesome, well-designed software thanks to the technologies and tools available to us today.

Just say no to this antipattern. Work with your managers and BAs to fix the status quo of requirements that engender this antipattern. It can be done, and everyone will be better off for it.

–written from my iPad mini in a session on scaffolding 😉


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s