1300 Peden, Houston, Tx 77006 | Contact Us | RSS Feed | Sign In

Depending on the service level agreement, it could be a lot! Our mission is to control the risk around the cost, schedule, and quality of what we do. If we miss the target, we ensure you’re not left out in the cold. Learn how we prove it.

Learn More

Project success doesn’t just happen. It’s the result of planning, managing scope, resourcing, risk management, and fostering a commitment to project results. Learn what we can do increase the probability of your project’s success.

Learn More

We define what we’re going to do, when we’re going to do it, how we’re going to do it, and why we’re going to do it that way. Learn how we can provide a higher level of transparency and visibility than you may be used to.

Learn More

What does your current provider offer to reduce your financial risk? Schedule risk? Quality risk? Learn how to approach your technology needs in a different way.

Learn More

An excellent opportunity for a motivated individual who can handle a lot of responsibility working to support the engineering team on new product development, bug fixes, QA/testing, and other critical development tasks.  Opportunity for the right person to use and learn many different technologies and architectures in a creative environment with other highly experienced developers. 

Required Primary Responsibilities and Skills

  • Write and manage a series of native windows services using VB/C# .NET  on a
  • Write and manage a set of DLLs designed to integrate with our SQL Server data warehouse
  • Analyze and design an enterprise level hosted software architecture
  • Optimize the performance of your code as well as pre-existing code
  • BA/BS degree is required, preferably with a degree in computer science/engineering or other engineering discipline.

Additional Skills and Experience

The following are items that are not required, but are seen as a 'big pluse' for potential candidates to have:

  • Experience with SQL Server Transact SQL development
  • Hosted software development background
  • Experience with ASP.NET (although this position is NOT an ASP.NET role)
  • Any MCSD/MCAD/ MCSE/etc. certification(s)

Compensation

Compensation is competitive and will be structured as base + bonus.  We will not relocate.

Location

Austin, TX

Apply Today

Click Here to send us your resume!

Primary Duties

  • Provide help desk and product support for customers
  • Document and troubleshoot software bugs and data related problems

Secondary Duties

  • Product license administration
  • Support website administration
  • Assist with customer training (online)
  • Product testing
  • Developing support related documentation

Required Skills and Experience

  • Good knowledge of drilling operations (2-3 years)
  • Experience in providing customer support for drilling reporting applications software (2-3 years)
  • Experience with database applications and some exposure to software languages
  • Good verbal and written communications skills
  • Experience in documenting and troubleshooting software problems
  • Experience in working with software developers

Location

  • Sacramento, CA

Apply Today

Click Here to send us your resume!

Responsibilities

Development and/or implementation in production workflows of tools and algorithms for image analysis required for the operations of the digital core analysis lab.

Required skills  

Expert level skills in object oriented software design and development, preferably in C++ environment.

Desired skills

  1. Familiarity with 3-D image analysis techniques and tools for 3-D visualization
  2. Familiarity with petroleum engineering
  3. Familiarity with computational mathematics

Education           

At least Bachelor of Science degree in engineering, geology, physics, mathematics, computer science or related fields.

Compensation 

Commensurate with experience and skills

Benefits

Competitive benefits, including health and dental insurance, 401k, vacation time, etc.

Apply Today

Click Here to send us your resume!

  • Twenty years of demonstrated leadership and proficiency in delivering telephony, converged networks and VoIP projects on time and within budget.
  • Extensive customer, vendor and upper management interaction with strong project methodology and life cycle skills.
  • Strategic Planning and successful management of multiple projects simultaneously ranging up to $6 million.

In our practice, software test automation can be an extremely powerful tool which if implemented properly can help ensure a successful testing engagement.  But the fact remains (as a lot of you may know first hand) that when not managed properly the use of automated testing tools will be a complete waste of time and energy and can even create substaintally more problems than solutions for the project. 

It is important to point out that it is not always necessary to automate all

functionality of the application under test.  In fact, based on my experience with software quality assurance it rarely makes sense to do so.  Usually it makes the most sense to automate the “happy path” test cases, core business rules validation and critical application functionality, and any repetitive tasks or test cases that must be duplicated thousands of time.  If the remaining functionality is relatively easy to manually test, and it will take more effort to develop automated test scripts, then continuing with manual testing.

The following list outlines some guidelines that can be used to determine when it is a good idea to introduce automated testing into the QA process of a software development project.

Test Cases Execution and Validation

At the start of each project we analyze the system from the automation tool perspective to determine the difficulty level of test cases automation. Projects are evaluated on GUI elements and overall GUI complexity, as well as identifying the applications use of validation patterns.  The more consistent the validation patterns, the easier and more effective test automation will be. More...

Imagine its late Sunday afternoon… you’re at the office, and have been all weekend.  You are diligently working to ensure that the Monday build deadline is met.   You have been testing your code, and all is looking good in your dev environment, so you decide it’s time to check in your code and run the build process.  But once you get the latest code from your repository the build no longer compiles!!! How frustrating!

Why did this happen… who is responsible… You could be here all night trying to track down the cause!  If you are working in a remote environment or on a multi-site team tracking down the problem will be even more difficult.

Now imagine that your development team uses a Continuous Integration (CI) process.  When anyone checks in code to the team’s source code repository the build is automatically run, and if there are any compile issues an email is sent out to the team.  Now you know exactly what code broke the build, and which team member was responsible.  Better yet, the issue can be addressed immediately.  But why stop at just compile issues?  Why not automate your suite of unit tests as well?  Throw in a code coverage tool and just imagine how confident you would be that not only your build will consistently compile, but that the new code you have introduced has not broken any existing functionality.

If your team does not employ any of the tactics mentioned above, you know these integration pains firsthand.  And while implementing a Continuous Integration process is not a change that will happen overnight, the time and effort spent in implementing such a plan will certainly be less than the amount of agonizing hours spent by team members tracking down such integration issues.

According to Martin Fowler:

The fundamental benefit of continuous integration is that it removes sessions where people spend time hunting bugs where one person's work has stepped on someone else's work without either person realizing what happened. These bugs are hard to find because the problem isn't in one person's area, it is in the interaction between two pieces of work. This problem is exacerbated by time. Often integration bugs can be inserted weeks or months before they first manifest themselves. As a result they take a lot of finding.

I recommend implementing your CI process in stages:

  1. Implement a Source Code Repository that meets the needs of your team.  For example, does it work well with remote teams (accessible from the internet)?, does it integrate well with other CI tools (auto-build tools, unit testing tools, etc.)?
  2. Document your build process and train all developers on this.  This should clearly layout items such as when you should check in your code, what structure you will use and what each folder is used for, under what circumstances to tag or branch the repository, how to version the build, etc.  The idea is to make sure everyone is familiar with and follows this consistent process.
  3. Once this is in place you should add the automated build component. There are a lot of good tools out there.  Finding one that integrates with your code repository is a must (this should not be hard).  Here is a feature matrix published by ThoughtWorks that is an excellent resource for evaluating which CI system is the best fit for your organization.
  4. Train your development team to effectively use test-driven development and strive to have the team write ‘self-testing code’.  This is the hardest and most time consuming step because this is not just a tool that needs to be learned and configured… this is a fundamental change in your approach to writing code.
  5. Automate the running of your unit tests.  Once the team is writing effective unit tests, you will want to have these run every time the build is compiled.  This adds an even greater level of assurance that everything is still ‘a-ok’ after introducing new code.
  6. And finally, use a code coverage tool to ensure maximum effectiveness of your unit tests.

From my experience, a huge problem that companies face when outsourcing their technology needs to an offshore provider occurs during the initial selection process.  For a variety of reasons, decision makers fail to apply the same level of scrutiny and process that they would if they were hiring a team of local contractors or permanent employees.   This can be due to the physical distance between the client and offshore provider, because the decision maker is overwhelmed by the ever growing number of offshore providers these days, or simply because the provider was referred by a trusted source.  Whatever the case, your engagement is important, so vet potential providers with the same intensity that you would any other local consultant agency, contractor, or employee… if not more so. 

Here is a list of 5 strategies to follow when narrowing down your list of possible providers:

1. Know Your Needs

Before making any decisions make sure you know exactly what you are looking for in your provider.  With so many choices when it comes to selecting an offshore technology provider these days, it is important to know exactly what your priorities are.   A few examples are:

  • Overall cost of the solution (this is always a priority)
  • Provider’s location and ability to travel to the US as required
  • Specific technology expertise
  • Longevity of the relationship (are you going to need the provider around to support the solution for several years?)
  • Familiarity or certification in a specific process
  • Amount of visibility into provider’s internal operations

 

Once you have determined your top priorities, make a scorecard that you can use during the evaluation process.  The bottom line is that every engagement is different – the things that work for one client don’t always translate to another, so make sure you have a clear picture of your overall expectations. More...