I’ve been working on my CFUnited presentation titled “Reviving the Lost Craft of Writing Specifications” and want to publish another teaser that might make it into the final version. This is raw, rough, uncut and unedited so beware.

//

What About Data-Centric Applications?
Early in the project, you need to determine whether this is a data- centric application or a UI-driven application. If it’s a data- centric application, then you should get into the existing data, or the creation of the ERD very early in the process. I believe that “version 2 rewrites” are data-driven applications. These kinds of applications may require some kind of data importer or massager if the database schema changes and importers can be one of the most costly parts of a software application and can, in some extreme examples, make requirements on the rest of the application by highlighting relationships among data objects. Also, if your data-centric application has a poorly-organized database schema which is unable to handle and manipulate the data set, the entire application (UI and all) will fall apart very quickly and may generally be unrecoverable. But the opposite is not true – a UI-driven application with a crappy database isn’t necessarily a recipe for instant failure. There are many large commercial applications with atrocious underlying data-storage mechanisms.

If the application is a UI-driven application or is a version 1 application or has no existing data to import, the database schema can be ignored until later in the project. But in either case, the prototype/wireframe must be created early and often. These two classes of applications are the only types of applications I’m talking about here. I don’t know anything about writing device drivers or scientific analysis programs, but I’ll bet dollars to donuts that those classes of applications also make use of spec docs in some format.