The Tao of New Features (Part 4)

This is the fourth of a 4 part series on the geoLOGIC philosophy of adding new features to our software.   Part 1 is here.  Part 2 is here. Part 3 is here.

Protect the interpretive data.
This is the most critical part (see this post for a little background on why) of what we do.
When you work this hard, protection is important!
If any change has the potential to affect a database that you have created, we have to provide an automated process to ensure that the data is maintained. We also ensure that before we perform any maintenance or upgrading operation to any user-created data, we create a back-up or archive of the dataset.

This mindset is also found in operations which occur in other parts of geoSCOUT.  We spent a lot of time developing processes in geoSCOUT to ensure that when you post data to the map it is saved automatically.  We have even gone so far as to decline to implement certain operations in the Cross Section module simply because that would make it easier for a user to accidentally destroy the Cross Section that they created.

And evey new feature needs to be tested. By itself and in conjunction with geoSCOUT as a whole.

We perform testing with our own sample data and solicit samples from clients as well. In fact it was just such a solicitation that provided us with a database template from one client who had over 1000 fields of data in their User Database. We stripped the client data from the template and used the template to create and populate a full UserDB with over 18,000 wells and over 1000 fields of data, which is now a part of the standard pre-release Acceptance Testing that all geoSCOUT software goes through. Let me take a moment to talk about Acceptance Testing, because of course every new feature needs to be tested.

We have 5 full-time Testers, as well as an automated testing suite.  We also have over 150 documented Test Plans which we execute up to 3 times before any release of geoSCOUT (and don’t forget that we have 3 of those per year).  Each Test Plan takes an average of about 6 hours to run through (some are shorter, some longer).  In other words, if we assume an 8 hour day and a 5 day week, it takes about 26 person/weeks to run through a full cycle of testing for each geoSCOUT release.  We also test on a variety of hardware and Operating System combinations.  We also draw upon members of the Geology, Support, Sales, Design and Documentation groups to supplement the Testing Team in the Release Testing cycles.  The end result is that by the time a new version of geoSCOUT goes out to you, every new feature has gone through at least 3 test cycles, and we have tried to ensure that we have tried the software on the types of machines and networks that you folks are running on (although, as my network manager likes to say, “Networks are like snowflakes – they’re all unique”).

There you have it.  The simple Tao of New Features.  Of course, we go through a far more detailed analysis on every feature that we bring in, but the first level of analysis covers these basic four principles that we address with every release of software from geoLOGIC. And don’t forget, we schedule software releases for 3 times per year!


About Sean Udell

Sean does not like to write about himself in the 3rd-person. He’s been with geoLOGIC longer than almost everyone else in the company, and some of the new hires weren’t even a gleam in their parent’s eyes when he started.
This entry was posted in database, geology, GUI, mapping, oil and gas, petroleum, Product Development, software, Technology and tagged , , , , , , , . Bookmark the permalink.

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 )

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