Case Study: Super-generic framework in logistics

Author(s): Sven

A very large logistics company hired a consultancy which to implement a web shop for buying products of that logistics company. At the heart of the system was a proprietary order engine built with a generic order framework. We reviewed the system and found the following behaviour:

It took almost two weeks to set up the developer workstation for developers not using Linux. Linux users could luckily make it in a few days. There were so many scripts to run to get Weblogic up and running with specific “framework plugins” and no one seemed to get it right. There was no documentation, everything was trial and error.

What is the system’s background?

What was the good idea?

There was the belief to build a generic order engine which could be reused across many projects of the client and projects with other clients.

What were the bad consequences, why was everything bad?

Implementing new features took forever. It was hard to understand the code base, but it was even harder to test it. Unit tests were not possible, integration tests were possible, but the feedback cycle was very long. The application domain itself was simple, but still we had enormous problems where you wouldn’t think you will have them. The idea to have two generic database table turned out to be a big performance bottleneck which required very specific Oracle knowledge to solve.

Which patterns were encountered?

How was the situation resolved?

The original consultancy got fired and a new one got hired to develop the system from scratch.