SSWUGtv
With Stephen Wynkoop
Do you know what is "Bachelor Programming Syndrome"?
If you watch this episode of SSWUGtv featuring Craig Mullins you’ll know for sure!
Watch the Show
Application Development Strategies – Reader Responses
Historically responses to these kinds of questions lean toward data driven design techniques. That’s not a big surprise based on the history of SSWUG. Even though SSWUG has expanded beyond database technologies, it is still a core aspect of what we do.
Today Ronald responds with a leaning toward domain driven development; applications started by Modeling Objects. He says:
There are 2 theories Data driven vs Domain Driven Design
Data driven is considered to be old concept vs domain driven is newer more on the line of OO development.
I read this article:
I would appreciate some elaboration on this topic.
In contrast, Jim demonstrates how data driven development grew from earlier days of computer programming.
Jim writes:
Back when dinosaurs roamed the earth (the mainframe days), we had CODASYL based network databases like IDMS with Cullinet tools (e.g., Culprit, ADS/O); an inverted list, relational-ish ADABAS with Natural; and a “little bunch” who published IMS and later DB2, and promoted or facilitated 3GL and 4GL tools (Informatics MARK-IV, Sperry’s MAPPER, Ramis, Focus, SAS, SPSS) with the promise of programmer-less application development (and there were scores of others including a product called Score) – all based, in whole or part, on a data driven, schema driven paradigm.
In the early days of the PC, after we got beyond VisiCalc and any of 100+ (yes, literally) word processing programs as the dominant software, dBase (and a host of others) took us into the sphere where apps on the PC entered the broad business realm. In the absence of programming expertise, many varyingly effective products were developed around these databases (ever hear of FoxPro) that used a Data Driven paradigm to build CRUD (good start) and codeless apps based on analysis (smart folks, if not, expert systems) of the database schema. Eventually, we got Access to Approach (formerly Lotus, now that “little bunch”) and eventually PowerBuilder. There were and are others.
My view, today, the data design has to be two (2) steps ahead of the app design.
You can (if not easily, methodically) refactor code. It is an expected part of application development, clumsy or agile. Try refactoring a database (I’ve done it and paid my pounds of flesh). Tell a programmer (ok, developer), to change her code to match the new and improved database design, absent overwhelming pain, and see whether you pull back a hand or a bloody stump.
I’ve been called on to rescue poor database designs, and done so (and, sadly, have sometimes failed).
The database must capture the goal, and dare I say, the vision, of what the system or application is being developed to accomplish. It is the roadmap, the skeleton, the rock solid or sand (I was thinking mud, but …) soft foundation on which code is built. It sets the boundaries or opens the vistas (sorry, MS) for the future.
Tools help; they make the process faster. They hide the complexity of the process. They exploit the intelligence of the data design and accumulated knowledge of what works. They facilitate the fact (patterns) that, under the covers, the best code looks more similar that different. The database design, when done well, captures the state (backward looking), dynamics (real time), and possibilities (setup/metadata) of the development activity, from enterprise to widget. And good tools utilize that intelligence to make fantasy real.
But, given a sharp saw, a block plane and a few simple tools, a craftsman can create wonders that a shop full of state of the art tools cannot approach in the hands of someone less able, or someone standing on a foundation of sand.
I have personally gone through a similar journey of experience from Data First and Object First designs. The interesting thing I find is that both methodologies are not mutually exclusive. For that reason i presented questions in previous newsletters which may help you define which approach best fits your situation.
I will definitely say that you learn new techniques for database development allowing it to easily be re-factored. It is a lot harder to change something when it already contains data than it is to change code. However, it can be done effectively, and it can be the best choice. Good understanding of normalization techniques will help reduce the amount of difficult refactoring you might experience. Seems like there is something there for an editorial because this would be way too much to cover in a newsletter. Maybe you would like to write one of those yourself. Jim already has a great start 🙂
Thanks for the replies from many of you. If you respond to Ronald’s request I’ll be sure to include it in future newsletters. You can respond by sending an email to btaylor@sswug.org.
Cheers,
Ben
$$SWYNK$$
Featured Article(s)
How to Handle The Situation That You Are Now The Boss of Your Peers (or Visa-Versa)?
In the previous SSWUG TV interview with Stephen Wynkoop, we covered "How to handle the situation when your peer is now your boss?" This is a more detailed discussion of that topic.
Featured White Paper(s)
NobHill SOFTWARE Database Compare Product Look
read more)