Durwella

The exploration industry has a persistent challenge in managing digital assets. Data is recorded in different methods by different service providers... Data is used across different software, and therefore derivatives may be in different projects and formats... It comes into your organization via different channels. And most data has a greographic context, which brings its own challenges. It can be tough to just answer the query: “Show me all the data relevant to this lease.”

Moreover, our understanding of the subsurface is constantly evolving. So updating data (or preventing the use of out-dated data) is another challenge.

Add to this all the normal challenges of IT data warehousing (like security, redundancy, search, speed & space) and you have multiple full-time jobs on your hands.

When analyzing data management challenges we recommend looking at 5 dimensions: Reception, Discovery, Indexing, Querying and Updating. For each of these dimensions we look at the current state of Practice, Policy and Technology. We also revisit each of the dimensions to ask what the Ideal scenarios would be.

The resulting matrix can be refined, and then used to suggest improvements to policies and technologies. If the response to any of the questions is “None” this is clearly an area for improvement.

For example, it is common to handle data reception in a very ad hoc way. That is, there is no policy associated with reception.

They emailed me the latest well log; I’ll forward it to you but it doesn’t have the X/Y’s. The coordinates are in the LAS from last week.

It is also common for there to be no technology associated with automatic discovery. And this is unfortunate because much technology exists in this area.

How often do important business functions get carried out in spreadsheets or Matlab Workspaces? How many engineers are calculating project parameters in these files that have been copied, pasted, attached, upgraded and downgraded over the years?

At some point it becomes reasonable to ask, “Should this worksheet be turned into a software application?”

The right software adds repeatability and quality control to internal processes. It becomes more intuitive and more robust. It can even become a source of profit. 

Nobody knows better than you do what processes and calculations are needed in your domain. Consider investing that knowledge in the development of custom software.

For any Visual Studio project, like an Intel .vfproj, that is not supported by MSBuild, it can be wrapped in a simple .proj file. The .proj file, just like a .sln, can be built by MSBuild on a machine with Visual Studio (and other needed dependencies).

Here is a .proj file to get you started. You will need to replace the solution and project names. You should also double-check the visual studio version.

<?xml version="1.0" encoding="utf-8"?> <Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> <PropertyGroup> <SolutionFile>$(MSBuildProjectDirectory)\Solution.sln</SolutionFile> <ProjectFile>$(MSBuildProjectDirectory)\MyProject\MyProject.vfproj</ProjectFile> <Configuration>Debug|x64</Configuration> <DevEnv>C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\devenv.com</DevEnv> </PropertyGroup> <Target Name="Build"> <Exec Command=""$(DevEnv)" "$(SolutionFile)" /Rebuild "$(Configuration)" /Project "$(ProjectFile)" /ProjectConfig "$(Configuration)" /Log" ContinueOnError="false" IgnoreExitCode="false" WorkingDirectory="$(MSBuildProjectDirectory)" /> </Target> <Target Name="Clean"> <Exec Command=""$(DevEnv)" "$(SolutionFile)" /Clean "$(Configuration)" /Project "$(ProjectFile)" /ProjectConfig "$(Configuration)" /Log" ContinueOnError="false" IgnoreExitCode="false" WorkingDirectory="$(MSBuildProjectDirectory)" /> </Target> </Project>

Note that we also include a Clean target. That is needed if your Team Build is configured to not require a clean workspace. This really speeds up builds that have a lot of source files (e.g. something including Boost).

Save the .proj alongside your existing solution and check it in. Then edit the build process to add a project. Add the .proj before the .sln. You will probably need to disable the building of the .vfproj in the solution configuration built by your team build. In that case you can add another solution configuration, different from the one developers use in Visual Studio.

Marc Andreessen on Why Software is Eating the World - WSJ (2011)

When teams form and discuss their “Definition of Done” it is easy to omit User Documentation. Especially in the early stages and when the team is small.

We recommend including documentation in regular releases (e.g. every 2 weeks) even in lean cases. And we are happy to do it.

First of all, it is not unusual for science and engineering algorithms to have many parameters. So it should go without saying there that needs to be some user guidance in the first release.

Less realized are the benefits that documentation offers along the path of development.

Demos, Demos, Demos

Demos can be required frequently for young software. Naturally we demo at the end of each iteration. But, investors, pilot clients, and potential employees can also require demos.

Documentation provides a useful script for all these demos, and it can be refined each time.

New Employees

It seems even mature companies can have a poor on-boarding process. A new software project is even less likely to have any extra mentor-time. While there is no substitute for one-on-one training, having up-to-date documentation for the product makes for efficient learning. And, as a reminder to developers, the next folks who need to learn the software may not write code for a living.

Testing

Mature QA organizations can have thousands of pages of testing scripts validating many modes of operation across all features. But when a tester is first hired he or she is likely starting from zero. Again, documentation offers a valuable starting point without costly coordination.

As a matter of fact, good documentation can serve as the source material for other important business functions: training, marketing, valuation, risk-mitigation, strategy, …

We use Microsoft development tools for much of our work. For an all-native C++ project we recommend their relatively new CppUnitTestFramework. It integrates nicely with Visual Studio and Team Build. Entry points are automatically registered, so you don't need to keep a running list of unit tests. And it is fast! Our tests average 1 ms each.

However, there is one glaring omission: the test runner does not show the message string from unhandled standard exceptions.

It is common for tests to fail due to exceptions. We take it for granted in our managed tests that we will get some useful information in the failure text.

So we wrote a small extension to unpack the exception message for the test output.

We have the following macros included from stdafx.h so they are readily available.

#define _TEST_METHOD_EX_EXPANDER(_testMethod)\ _testMethod { try // Adds support for seeing std::exception in test output. Requires TEST_METHOD_EX_END after test. // Example: // TEST_METHOD_EX_BEGIN(MyFailingTest){ throw std::exception("What happened"); } TEST_METHOD_EX_END; #define TEST_METHOD_EX_BEGIN(_methodName) _TEST_METHOD_EX_EXPANDER(TEST_METHOD(_methodName)) // Use following test declared with TEST_METHOD_EX_BEGIN #define TEST_METHOD_EX_END\ catch (::std::exception& ex) \ { \ ::std::wstringstream ws; ws << "Unhandled Exception:" << ::std::endl << ex.what(); \ ::Microsoft::VisualStudio::CppUnitTestFramework::Assert::Fail(ws.str().c_str());\ } \ }

Use it as follows:

TEST_METHOD_EX_BEGIN(ShouldIndicateWhatWentWrong) { throw std::exception("The system is down!"); } TEST_METHOD_EX_END

These days, the concepts of startup businesses and software development are so tightly linked, it would be hard to ignore the allure of joining a startup.

However, joining a startup usually means accepting below-market wages in return for equity of questionable value.

At Durwella we offer our employees the opportunity to have the start-up experience without sacrificing compensation.

Many of our clients are entrepreneurs. They bring their vision, marketplace understanding, and experience to us for the opportunity serve a larger audience than they can on their own.

As we build applications and plug-ins for them, they begin to build a business. And in our heart of hearts we want them to succeed.

We love applying computer science to applied science.

We particularly enjoy speaking with college students and hearing about their research areas. They are often surprised to hear how their knowledge could be used here in Houston.

Signal processing, computer graphics, numerical methods, image recognition, artificial intelligence, … We’ve seen how all the major fields of computer science can be put to rewarding use. And we work with clients who need technical and practical solutions.

Too often the passion of the newly graduated computer scientist is sapped by maintenance of legacy systems. Yes, sometimes we will need to use a legacy Win32 API or link with a Fortran library. But, we strive to quickly build higher abstractions to solve interesting problems in ways that delight our clients.