About 20 years ago I started writing software. I was defraying the cost of my tuition at Pfeiffer University in North Carolina by working for the Dean of the Undergraduate program. After being introduced around, I was given the task of finding out how many students had enrolled in BUS XXX, it was close to full. I asked where to find a computer. The Dean wanted to know who I was going to email, that we flipped pages in the registration book and made tally marks on a legal pad. I quickly informed her that in 1997, we didn't make tally marks, we did a database search. At the time, I had seen Windows 3.1 briefly, and had no idea how to design and build databases or database applications. The next day, I came in to a new office, with a door that locked, a brand new computer and the marching orders "Make a database." 15 months later, ALL of the processes in that office were automated, and I went to work for Microsoft as my first Post Graduation employer.
It's a cute story that has the advantage of being true. It also illustrates the way that most of us got into the software writing business and why software is so expensive and unreliable. Here is a college kid writing an enterprise application. Luckily, I turned out to be pretty good at designing and building databases. Databases are the foundation on which all other software is designed and built. Not long ago I had that very discussion with a colleague of mine who stated "You don't need a database for a document and you don't need a database for a spreadsheet. I guess Microsoft is wrong then, because the entire suite of Office applications is nothing more than a User Interface (UI or GUI) for the Jet Database engine. Where do you think all those preferences are stored for your word docs, and why do you think you get a temporary locking file that looks ghostly in the same folder as your original document? Yes, I know it isn't quite that simple, but the locking file isn't far off either. Excel sheets are nothing more than a graphical representation of a Jet Database table.
Why is this relevant?
My colleague, Randy, is an incredibly talented software developer. He was wrong about needing/not needing a database, but his assertion supports my thesis that most software developers just fall into writing software and why that's not a good thing. In subsequent blogs, we will discuss why we need a database and how Set Based
code and Procedural
code differ and the hows and the whys of using either one. Some of the discussions will get fairly technical, but the average interested layman should be able to follow along and if he employs developers, should be able to not only ask questions that make them REALLY uncomfortable, but understand the answers and when they are being less than forthcoming with their responses.
Usually, we will start with an anecdote or a case study, like we did today and talk about the solution and why we picked that particular design to showcase the 'how to' part of what we are doing. Follow along. You will
read something you don't agree with. Comment on that. Maybe you can teach me something as well.
I am going to be posting this at the Sentia Systems Website
as well. Go and take a look at some of the older posts there that I haven't yet included here.