When I made the switch to consulting a year ago I did so to emerse myself in a faster paced environment. I enjoy new and exciting challenges frequently. I thought most of my challenges were going to be technical. But I’ve discovered a good part of my job is channeling and focusing the client’s desires.
I’ve had the good fortune of working on two stellar projects in the last year. One involved creating a proof-of-concept application using all the bells and whistles in .Net 3.5. It included WCF, WPF, and WF. My second, and current project, is a highly scalable SOA architecture. My job has been to come in and expand it intellegently. In both situations the clients have had extreme desires to push the limits of not only their software but of the .Net framework itself.
Case in point, on my current project I was given the task of interfacing with a printing vendor. We needed to ship them documents on a daily basis. I was told to use an existing pattern/system of windows services to send the documents and web services to receive the documents. This pair of software would be installed on both ends making it easy for us to send and receive documents on demand.
In theory it’s a very simple concept. We failed to anticipate, though, was the complexities of dealing with a third party’s server environment. After struggling through configuration after configuration errors (no errors were in the software, mind you) I asked the printing vendor how they typically receive documents from other businesses. “Oh, FTP, ” they replied. I asked how many of their customers require custom software installations like we were. “Zero”. We re-invented the wheel.
The problem now with having our own “wheel” is now supporting our “wheel”. We are now on the hook for any issues that may come with our process. If we would have gone with their standard process of using FTP we could have gained so much more in managability, logging, exception handling, etc…Which our “wheel” could have if we had the time and money to add such features.
