U.G.Wilson²⁴

I am excited to announce that I will be relocating to take a job with Brockwell Technologies, Inc.. 

I am also sad to announce that I will be leaving Northrop Grumman in order to take this position.  I have enjoyed my time with Northrop immensely and would not trade my time there for anything.  I have worked with some very talented individuals and management and wish them all the best in the future.

Story Time

Let's us say, for giggles as my late grandmother might say, that in a corporate environment it takes 45 minutes to build a reliable send e-mail function for a web application from scratch.. Now, over time, 2,500 e-mail enabled application are construction internally and externally.  This means that the given corporation has spent 1,875 man hours constructing the function SendEmail(...).

"My goodness!", one might exclaim. "We must build this once and for all, so that our colleagues need not waste valuable company time on such a menial task!"

The solution is simple, build a library full of commonly used code, stuff it in a repository for all to modify, improve, and utilize! Right? Well that works wonderfully at Bliss Co. where 'Rainbows are Our Business!', but we have to address some realities of the corporate condition.

Order from Chaos

There are many great developers that write wonderful, beautiful, and efficient code; however beautiful efficient code isn't typically very flexible.  It might be easy to climb up onto your chair at SmallCo Inc. and let it be known to the cubes around you that you've just added the SuperDuperSpecific class that operates at a 10 millisecond time savings over the CanUseAnywhere class, however that simply isn't the way a corporate environment works.

Two people adding some less-generic functionality to a small company library once a month isn't a big deal, but 100 people adding single pieces of less-generic code to a library monthly and you end up with 10,000 other employees trying to keep up with what's new while trying to do their jobs. This is of course is assuming they try to keep up at all.

So who masters this three ring circus? The project manager assigned to the library construction effort? The guys in accounting who realized how much money 1,875 man hours equates to? Well ideally in the software realm the customer decides what they want. It just so happens that this time the developer is the customer.  The developers are the ones who know what functionality they've written nine times since last Tuesday.

The trick is providing a methodology for reaching a consensus, but consensus of whom? These disjoint blobs of developers from the vast reaches of the corporation? It's this question which brings us to our next topic.

It takes a Village

Has anyone ever seen a useful API or piece of software that didn't have a thriving community behind it?  A useful corporate library isn't going to be tiny. It's going to have to meet a lot of different needs, and developers are going to need a means by which to sift through chaff and find what's actually relevant to them.  Useful communications tools and up-to-date documentation are, in a very literal sense, more important than the library code itself.

If it takes me 5 hours to even find the documentation on how to use an OpenID extension to the .NET Membership architecture and an additional 6 just to figure out how to use it, I'm going to write it myself. One could argue, "But U.G.! You could save all that time later when you have to implement it again later on down the road!" To which I calmly reply, "Alas, my for-thoughtful friend. I have a deadline of this Friday, and I can implement my own solution from scratch in 8 hours."

What's further depressing, in my mythical situation, is that I know that someone, somewhere else in the corporation has asked someone how to use the OpenID extension, and received a generous explanation. Do I have access to this? Of course not! It likely took place over a twelve e-mail conversation that is lost in the annals of a exchange server. An internal developer community is not only a valuable commodity to a corporation, but a foundation for the success of a reusable library.