Time to read: 2 minutes.
by Mike Slinn, an unpublished work. All rights reserved.
An email arrived from someone I didn't recognize. “We are looking for an expert who can evaluate our software product. We are a provider of web-based project and portfolio management software and had our product developed by a third-party company. As the code was transferred over to our company some weeks ago, we seek to have an outside person doing an evaluation of whether or not the code was programmed according to the specification.”
I called him back, and learned that his company had engaged “SoftwareRUs” to design and develop a three-tier application using WebLogic and Oracle. The six-month project was now a year over budget, and no end was in sight. They were attempting to negotiate a refund, with damages, as per the terms of the contract. Would I be able to establish factual evidence to support litigation against SoftwareRUs, should negotiations between the two firms break down?
This sounded like an interesting assignment. I agreed to visit their offices the next day.
I was treated to a wonderful overview of the history of the project by the project manager, and then talked with the CEO about the matter for a considerable period of time. I noted that SoftwareRUs's original timeline called for only one day of design, in a 2000+ man-day project. Although there were many possible approaches that I might take, we agreed that the most cost-efficient way for me to spend my time was to manifest some concrete evidence that the system had not been properly architected in the first place.
Software development is ultimately about code, so I sat with two members of my client's technical staff and we took a look at the code. "There are hundreds of files here, including a servlet for every JSP," I was told. That is unusual. The directory structure seemed reasonable, so I picked a few Java source files at random and looked at the code. It all seemed to be at a low level, like there had been little abstraction or object modeling – not surprising if no design time had been allocated.
"There are too many files for me to attempt to piece together the object model this afternoon," I said.
"Let's try a statistical approach instead."
I ran grep on the files, and found some fascinating results.
There were 983 total files in 12 directories, including:
16 htm* files
220 JSPs
618 Java files, consisting of:
0 interface definitions
0 custom interface implementations
0 abstract classes
2 derived classes
Of which:
190 are applets
220 are servlets
2 are session beans
0 are entity beans
0 are message-driven beans
What this told me was that after removing all files that extended standard Java classes, only SoftwareRUs had only written 2 base classes. Their design didn't use any interfaces either.
The software design implemented by SoftwareRUs seemed more like a high school student's attempt at two-tier programming, since the middle tier (the WebLogic EJB server) was largely ignored. In order to prove this fundamentally important point, I decided to take advantage of what appeared to be a lack of abstraction. The following magic incantation told me how many servlets directly called the Oracle database:
