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

Tool chains

To any person who works to create anything, their tools are the most important items available to them, be they a woodsman, a mason, a photographer, or even a software developer. The latter profession, often defending their own tool set with what can only be described as a religious fervor the likes of which might be construed by the casual observer as bordering on maniacal ravings. Often enough when one digs about such heated discussions one cannot help but feel that one side or the other might harbor some deep seated apprehension.

"perhaps my adversary in this fight is correct?..... Na can't be the superiority of my own {insert environ x here} is irrefutable... Besides he's a ding dong anyway"

Well I have often enough felt that way with my own development choices. Of late however I have found myself yearning to really know if the other guy was in fact a ding dong. I have found myself wanting to really know what the other sides tools are really like. Having no real spare time for anything, the only way that would happen is if the company I work for branched out a bit from their standard platforms and embraced something different.

As is always the case in these matters, changing course is not easy. One needs to make a rock solid, water tight business argument for the case and maybe said argument would not fall on deaf ears. Such was the case a few months ago when I approached the powers that be and made the case for doing some real development for the apple platform, specifically the iPad/iPhone. The case of course being that finally a compelling form factor was available for a touch device we could bring some of our applications onto. We do a lot of crud style applications with scads of human input forms. Often enough the clients we do this stuff for send the users into the field with bulky laptops equipped with air cards and believe that the problem is solved. In reality though a laptop creates a number of barriers between the person taking the information and the source of the information. Not to mention that sending a person out into the world with a laptop in many cases is painting a bullseye on their backs. Many of our clients have to venture into places in our society where that is a real concern. So the iPad makes for a compelling firm factor to reduce these problems. The company felt like I do and we sprung fir a development platform and some other equipment to employ.

Now I will freely admit that I have had exposure to other development environments in the past, so I was not surprised to find life on the apple side of the river different from our primary development environment of Microsofts visual studio environments. I've used eclipse on various platforms (Windows and Linux) as well as a few eclipse variants, have written code in java, c, basic, c#, visual basic, fortran, COBOL, modula 2, forth, assembler... The list goes on. Most of these efforts had what could only be described as minimal environmental support, you have some form of command line compiler, and an editor of some form where you create your code. You hand the code file to the compiler and cross your fingers. If all goes well you get an executable that you can run on your target platform. I am not really calling these tools into question because don't consider them real environments.

I have worked with visual studio now for years, vs 2003 through the current vs 2010. That is an environment. Now on the apple side of things we have Xcode. It's the tool of choice for the apple crowd targeting iPhones and IPads. Apple has had some time with this product and it's now up to version 3 I believe. It consists of the editor, integrated with the file manager style of application like solution explore in visual studio, the debugger supporting all manner of the things a decent debugger should support as well as a user interface builder to facilitate creation of the human interfaces necessary in a typical business application. So I did not find Xcode to be all that unfamiliar. You will note that I am not even talking about the language, or the os on the target platforms, or even the style of human interfaces supported on these devices. These are different devices so there will be language and style differences I fully expect that. What I did not expect was the relative lack of any form of automated help for such things as simple event connection in code to ui elements on the human interfaces being built.

Case in point....
To create a simple form with a button on it. You might thing that placing a button on your interface, naming it something intelligent would expose it to your code. Well I found that was not the case. To expose it to your code you have to create something called an outlet. This in effect creates the code entity that represents your button. Then you have to physically connect that button to the outlet by dragging a line from the list of outlets to the designer representation of your human interface. Finally you can then switch over to your code window and you have the code representation of your button. Wash, rinse, and repeat, for every element on your human interface. I have not even detailed the complexity of the actually building the outlets themselves or any of those details. I am just dismayed that the tool provided is so weak in this simple area. I guess I have been spoiled by what in comparison a very advanced tool in visual studio. Working in Xcode feels like employing stone knives and bear skins.

So yes the apple fanboys who scoff at visual studio as a tool don't know what a real development environment can be like and yes they are ding dongs.....



- Posted using BlogPress from my iPad

It's been a long time

It's been a long time since I posted last. The few stragglers into this dusty corner of the Internet have no doubt felt it yet another dark and dingy alleyway along with countless others that litter the web like trash on a city street. Fact is I have been extremely busy over the past year. Our company entered into a nearly impossible task that has been all consuming for some time now. A year ago we started with this task, that, after 52 plus 80-100 hour weeks finally is nearing a stage were the now 60 hour weeks seem a breath of fresh air. Truth be told I am onto another impossible task for another client, who at least appear happy that we are there delivering something. The prior death march has been taken over by others in our company to carry on with the good fight as it were.

My new exercise in the job of creating time where there is none, has me doing much of what preoccupied me in the past year. All this however with the lens afforded by the year of starts, and stops, and outright mistakes that we are now forced to live with because it's to late now to change. With that however I can't help but feel optimistic that this new set of hurried developments are better as a whole than the set we pulled out of our backsides on all those sleep deprived weekends spent in the hotels away from home over the past year. This is different, I keep telling myself, the system is better. In many ways it is. The blatant mistakes made on the last mortality parade have been addressed in this new architecture. Yet some mistakes continue, completely unrealistic time frames that seem to become even more so as their original unfathomable deadlines looms on the horizon. "Objects in mirror are closer than they appear", yet I am looking forward not in the mirror. I actually am writing this from a plane out of Chicago, not on a business trip but having taken a whole Friday off an half of the preceding Thursday, that's something that never happened in the other year long forced march. I am struck as I sit here looking at the fact that I have effectively 6 weeks of coding that need to hit testing in a little over a week. I am struck with the guilt of knowing that I just blew 3 days (Saturday and Sunday are prime coding days just like the Monday through Fridays of a normal work week). The fact that next week brings an all to familiar hotel room on the road, with it's marginal Internet connection, crappy tv, blacked out local sports and all, I have come to realize that nothing has changed, and nothing ever will.


- Posted using BlogPress from my iPad