Snake oil.....

We have been involved in some very large development projects over the past year. These projects have been large enough to warrant the inclusion of a number of parties in oversight that have been, shall we say, "not contributory to the actual development of the product". Now any time you find yourself in projects such as these, there will be parties involved that are there for purposes not contributing to the systems being developed. Sometimes these people are there to ensure regulatory compliance. Sometimes they are there for documentation purposes. Finally you might find folks who are there to push agendas that are counter to what you might perceive are necessary to ensure targets get met. This final group is the reason for this jaunt into the blogosphere.

My most recent encounter with the latter was from a company that I will call "Bunko Corp". The project was undergoing some very strenuous times under what could only be described as impossible time frames for delivery. Truth be told we were definitely not going to make these time frames, and the client felt it was necessary to call in the "big guns". Bunko showed up and after a costly audit, and time wasted, came up with a report exposing what they believed were our shortcomings. Now, I freely admit my mistakes when I make them, which is certainly frequent enough to keep me humble, but as these things usually are put together, the report had little basis in the realities of the situation.

Central in the report was our apparent lack of adoption of what they refereed to as the standard and accepted practice of adopting a big iron framework onto which we would build our application. This entity framework was supposed to solve all our problems. It would automagically make the problems evaporate, as if somehow the framework would make the constant change in requirements phase into a solid form. As if it would solve the issue we had with the client making changes to the end user experience. As if the framework would make the data ambiguities from the old vendor disappear. The framework, they insisted, prevents and soothes all that ails you.

Now it should be told that we we not completely in the clear here. We were definitely guilty of having bitten off a mouthful. The time was very short, and were were definitely under the gun. We did not however adopt some fly by night architecture, that was unproven in the industry. We employed Microsofts SQL server enterprise, and Server 2008, and IIS 7. To meet the browser requirements we employed silverlight, and Web-services for the data endpoints.. Fairly standard stuff for this kind of project. The most eye raising choice in all this was the use of Silverlight for the user interface. This was chosen because of some fairly specific requirements for usability that were just not doable in a traditional asp.net web site. Given the tight time frames which even at the outset were apparent and our experience in traditional client server interfaces based on c# coding, Silverlight was seemingly a no brainer. Bunko Corp felt otherwise and said so in their report. All along, pro porting that the adoption of an additional software layer in all this, their precious entity framework, would have avoided the troubles being encountered.

Most of our mistakes in all this centered around issues that existed in meat space, and no magical fairy dusted bag of software tricks were going to solve those problems. Those issues were, and only are, solved through painful learning on the job. One example had to do with the switch over to SSL encrypted forms authentication through the web server farm. The Bunko wonks would have you believe that the problems encountered there were the fault of not having adopted the entity framework classes for the communication layer. In reality, a single line in each of the web servers configuration setup, forcing a specific key for the encryption used, solved that issue. (one example of a meat space mistake)

Another example cited in their arguments for the adoption of entity frameworks had as exhibit A: the fact that we had coded a number of similar endpoints in the web services that operated on different data sets depending on need. Bunko's argument was that we had way to many endpoints, and that the sheer numbers of said points were impacting system performance. Ignoring the facts that web service endpoints unlike true method calls in .net did not allow for operator overloading, forcing similar operations on different arguments to be made on a different endpoint, unless one adopts a sort of super sparse data structure and employs packers and unpackers at each end of the call. If we adopted said structure the impact on coding time would have been enormous and I fail to see how adoption of the entity framework would have had a positive impact on that issue.

Still, Bunko insisted that the project would never see any measure of success unless these frameworks were employed, despite the facts that the project was already operational. They insisted that we should undergo a redevelopment effort with their people working in parallel on version 2 of the project, with version 2 employing the framework and version 1 left to wither and die on the vine. That the framework version would have none of the problems of version 1.

Now here we are, a year later, that project has been operational now for almost the year. There have been issues but it is definitely going, which there are certainly aspects of the underlying system being replaced with newer and better pieces, the adoption of the entity framework as pushed by Bunko Corp never happened. I am onto a new impossible project with the experience of the last year of 80+ hour weeks fresh in my mind and indeed the newer project has started out on a better foundation, sans any adoption of the entity framework. In our new project however, we are doing a number of things new, in an effort to address the problems faced in the last year albeit still with 80+ hour weeks.

Facts are that through all this we have framework like employment in the techniques used. We have a consistent use of format and function on the data being handed off to and taken from the system. We have tools we wrote years ago that abstract the data layer from the actual store to the classes use to interface with that store. The tools that write code for use employ standard practices such as parameterized queries and the like. New in the latest development efforts are standard ways of dealing with errors on the web service side, and a consistent mechanism for dealing with errors. We have consistent logging mechanisms and other things that a canned framework might provide.

Recently I was asked to look at a large PowerPoint from another Corp let's call them Krapco Corp. In this case the slide collection was selling the notion that adoption of their own set of libraries in their "framework" would solve all your problems. Krapco's latest concoction, built on top of the same entity framework pushed by Bunko Corp, represented the latest in industry standard ways of solving industry standard problems. Their power point presentation, rife with all manner of layered architecture diagrams and other pretty pictures of where in the flow their particular bit of library would provide just the grease to silence your squeaky wheel. In the end they are even so nice as to tell you how to insert their piece of proprietary library into your development environment, their example citing how to insert it into Visual Studio 2005?.... Yup 2005... A sign certainly of how old their particular set of answers actually are.

When asked about our interest in said framework adoption I would retort as I spit on their pressed white suits, "Does it remove stains?"


- Posted using BlogPress from my iPad

Location:Thurber Blvd,Smithfield,United States