Offshore Technology Audit

Can you identify with these concerns?

The following are some of the problems that our clients have experienced with offshore projects and what we found upon investigation.

The applications do not install and run.
The build process is not managed and thus not repeatable, resulting in inconsistent deliverables. (This violates a primary dictum of the SEI level 3 requirement for demonstrating repeatable process and results.)
Non-incremental approach to deliveries, resulting in a broken code base between releases.
Massive (ineffecient) efforts required to get out a release.
Scheduled deliveries are missed.
Little attention is paid to the client's future intentions, resulting in a short term application with poor extensibility.
A cultural disposition to avoid questioning (i.e challenging) of the apparent requirements in order to better tease out the underlying real needs.
Many requirements are not fully, or correctly, satisfied in the design.
Inadequate design documentation.
Inadequate time paid to the important aspect of the initial design of the testing strategy. (Good tests make good code.)
Many features do not work (correctly).
Testing has inadequate coverage. 1) too few unit tests 2) too few functional tests, 3) no formalized regression tests 4) tests only cover one case where many variants/use cases might exist.
Inadequate version management procedures resulting in version skew during intense design activity periods.
Poor coding practices. (Inconsistent coding stds. makes code difficult to follow, interpret, fix or modify.)
Lack of good clear comments in the source code.
Lack of sound "refactoring" policies during development resulting in the unhibited growth of tortuous, unmaintable code.
Poor use of well documented design patterns which would have resulted in a more robust application ...........and a much shorter implementation time.
Insufficient leveraging of abstractions, which would have improved reuse and cut down on lines of code. (Also reduces build times, cuts down on testing, and produces a more generalized, extensible solution.)
Massive use of "cut and paste" resulting in bloated code which is difficult to maintain, usually inconsistent with the rest of the code, creates suspicions as to the origins and ownership of that code.
Use of non-portable design and coding constructs. (Over-employment of vendor features and proprietary extensions.) This vendor lock-in costs our clients mightily in license fees. Later in the project, as an attempt to mitigate this, multiple sets of stored procedures were added to support other DB products but this was done such that they dramatically impacted support complexity and cost. Futhermore inconsistent maintenance (by different developers) of the various stored procedures, over time, caused behavior between implementations with the different DBs to drift.
Combined functionality: Usual good programming practices call for a function to do just one thing. We see many instances of functionality being combined such that clarity of the functions is masked. When debugging code other developers often created unintended side effects as they tried to work their way through the combined function code and change it (incorrectly) to resolve issues. Problems were compounded.
Non-deterministic behavior (i.e. unpredictable performance.) We rarely see evidence of any analysis of code critical paths with a view to providing a consistent (i.e. satisfied) user experience. Such analysis also helps forestall scaling problems. We often see application lock-ups caused by race conditions, threading problems, poor synchronous designs, and bad exception handling.
The GUI application often reflects changing business conditions and must be optimised to support change and extension. The use of visual tabs is a frequently employed technique. However each tab should should have its own controls in a dialogue box. Too often we see one dialogue box supporting multiple tabs. Each new tab adds degrees of code complexity way beyond what would be needed with one dialogue box per tab. Is no one responsible for ensuring such bad practices do not get into the code base. Such implementations create massive impedance to change in an area where change is rampant.

By the way, you might see these problems onshore, as well as offshore!

Many offshore suppliers tout their Carnegie Mellon SEI level rating. However SEI focuses on process not code quality. We also know it is not easy to deliver good code with a broken process, and a good process can in fact make a good developer "great". However, even a superior process can never make a bad coder a good one. Process amplifies the good and the bad.

The off shore company's goal is to deliver product and ensure the client becomes totally dependent. The OCI value proposition is interdependence based on a partnership with our clients. Many times when we deliver to clients they not only get the code, mentoring during development but also access to the process tools that we utilized when developing their code. The OCI bonus for our clients, if they wish, is the open source based process and tools we used.

If so, OCI offers:

Third party offshore technology management services covering any, or all, of the following.....

A quarantine center where applications go for initial assessment. OCI engineers follow your provider's instructions and either install the binaries and test, or build the applications to validate the build and test process. Code does not leave until it runs and checks out.
An OCI hosted build and test center. As the code base expands, code is checked in for nightly builds and tests. OCI validates the tests, their coverage and their evolution from simple unit tests to more elaborate functional suites.
Architectural reviews of the use case development, the OO design, associated technological risk and identification of management strategies to ensure the project is able to be implemented by your provider's team.
Feedback to you the client, regarding the requirements, with a view to ensuring they are unambiguous, testable and reflect a good understanding of the business context.
Create the test architecture to ensure testing commences as early in the cycle as possible, until complete coverage is achieved at the completion of the implementation.
Version management of application code check-in/check-out, build procedures, test suites, design decision memos (DDMs) etc.
Monitoring of coding with a view to ensuring best practices. Including comments sufficient for self-documenting tools.
Evaluate the codebase at intervals frequent enough to determine the appropriate times for refactoring. Identify candidate areas for refactoring.
Promulgate the use of well established patterns to minimize risk, improve code quality and identify emerging patterns as abstractions to improve code reuse.
Oversight of static and dynamic design cases, establishing the exception handling models, so as to limit aberrant application behaviors.
Establishment of a request tracking (RT) system and monitoring of (RT) traffic to ensure timely and quality responses by your offshore provider.
Establishment of a bug fix, test and patch release process to monitor your provider's activities.

Provide competitive bids for aspects of the project ensuring you have a full range of real cost, schedule and quality choices, not just decisions driven by low cost.

The OCI delivery model focuses on early and then frequent deliveries.

For more details on getting your projects on track, contact sales@ociweb.com.