Preliminary Build

By know you know that a ton of time and effort has been spent on ripping the guts out of the good old ’69 Mustang. And what have I got for it? The ability to build it up the way I want. If I want to bore out the engine block, I can do it. If I want to put in a killer sound system, I can do it. But, I get ahead of myself. What I really want is a functioning, wheels moving forward vehicle. Not totally stock but not totally tricked out either.
This brings me to the topic of today’s post, the preliminary build. And how can you do a preliminary build for a car? Isn’t a preliminary build just another way of saying “Well, our first try at that turned out to be wrong, so we are doing it again”? Maaaaybe. It is about trying something, seeing how it worked out and then taking your learning’s (or lumps) from it to do it better the next time. Replacing the electrical system in a car is a huge undertaking. Especially if you are a grease monkey, not a wirepuller. But a tremendous amount of knowledge has been gained from tracing every wire from the fuse box out to the end point (radio, light, heater, starter, etc) by

  1. Ensuring that it actually got there.  Sounds simple right? Well, when you are dealing with approx 50 wires of varying colours and shades of colours and you are upside down looking at or under a wheel well to fit it in, it’s not that surprising that one or three get mislaid.
  2. Ensuring that it brought power along.  Ahh, the infamous pinch. This was one of the reasons that I decided to replace that 40 year old + wire. I did not want an old wire that looked okay but was pinched inside to be causing me problems. But in the pursuit of laying down the new wire in that incredibly hard to get at place, it happens. Sometime. And only careful inspection and voltage checking insures that when 12v goes in, 12 v comes out.

So yeah, this is turning into a larger & longer project than I first thought, but now that we have seriously knocked out a dozen or so electrical gremlins out and only have 1 left. I feel pretty good. The car runs very nicely (pre tune-up), it just does not have all of the electrical system working. And if you think that I am going to drive my car without listening to some Beatles, you are mistaken.

Now to discuss ‘PPDM in a Box’ and the work on it’s latest release; v1.2. A lot has been learnt on the internals of the application (both DB & middleware). For example, one item around data management is dealing with when a record was created and when it was last updated. Pretty important stuff when you deal with data that has SOX implications. And when you deal with a data model that has over 1700 tables and you have 4 columns per table to update data to, it leads to a lot of extra time/effort/maintenance. Fortunately, there are things like database triggers that can be implemented once and never touched that will mindlessly do these simple date/user capture tasks over and over again; consistently I might add. But not everyone has good experience with triggers and rightfully so. Without a carefully planned architecture, they can be a maintenance nightmare and the start of a true ‘black box’ where good stuff goes in and ‘most of the time’ better stuff comes out. Anyway, the development team is at a crossroads on what to do with this. We do need to track who or what process created a record and then who or what process was the last to change it and report on it but man, we have a long list of enhancements already…. So it got put on the back burner for now. Or so they thought. I went through and created the database triggers for both Oracle & SQL-Server and implemented them on the development databases. We have been using these databases for the last 2 months for running our code against, inserting wells, adding production, tests, cores, renaming wells, deleting business associates. All stuff that is normally done in PiaB. And I have yet to hear a peep or see a bug report that says one of these background triggers stopped working or caused something to fail.  Do I see a future article on data quality here?  I think so.

Does this fall under the category of preliminary build? I think so. We are a lot smarter now because we know that these triggers can work silently in the background and do. We still have to implement this in a true production release, which means trying to think of ways to stress test it. But I think loading in a couple of billion production rows will do that…

In summation, we are not there yet for either the 69 or PiaB. But we have picked up a few knowledge points along the way. In fact, we figured out that when restore an old car, you can never, never ever ground it enough. That point was brought up AND reinforced by the chief mechanic’s thesis professor (yeah, don’t ask how that conversation came about) who, it turns out restored a car when he was in grad school oh so many years ago. And we learned that sometimes database triggers are a very good thing that saves time & money and adds consistency; they just need some care and feeding and architecting to make them add business value.

Advertisements

About Wes Baird

PPDM Evanglist and PiaB Product Architect
This entry was posted in Data Management, geoLOGIC, Product Development, software and tagged , , , , . Bookmark the permalink.

Leave a Reply

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

WordPress.com Logo

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

Google+ photo

You are commenting using your Google+ 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 )

Connecting to %s