tight-binding and developer optimization rant
reading this post from rj reminds me of what i have come to dis-like about the last year or so of MS development tools - tight binding.
in the post, Jennings rails against a behavior of Microsoft's Entity Framework library that forces renaming of objects to follow a singular/plural pattern. no question, that stinks. however, for me, the annoyance runs much deeper. i actually opt-ed out of the entire EF pattern two years ago. and i don't miss it one bit.
the problem w/ EF and other ORM-like patterns is that they are aimed at optimizing the developer experience. wrong target. optimizing the user experience is better. optimizing the application/network experience is *much* better.
most developer optimizer (DO) projects involve some level of code generation either by producing source code classes or by producing compile-time code. sometimes a DO happens within an editing environment and enforce a particular coding pattern that is better understood by the editor. the code doesn't run faster, but the editor likes it better. Charles Petzold's Does Visual Studio Rot the Mind? covered this pretty well back in late 2005. it took me a bit longer to arrive there but i, too, have grown unhappy with the trajectory of MS tools.
the biggest offense occurs when code becomes too tightly bound to data. basically, the idea that any data collection should be a compiled class. that any 'conversation' that involves that data collection should be a set of well-known methods (CustomerRead(), CustomerAdd(), CustomerWrite(), CustomerList(), CustomerQuery(), CustomerListOfFolksWithBlueEyes()). it all sounds so nice when you start out. but anyone who has to maintain long-lived applications built this way knows the horror of it all. just the smallest change results in a cascade of re-coding and re-compiling that offers the opportunity to introduce a myriad of unanticipated bugs. and woe until the poor dev that experiences a bug somewhere in the bowels of the generated code pile!
this nightmare is particular common in widely distributed apps like those that live on the Internet. if you software is at all popular, it can generate a collection of ad-hoc clients built by creative admirers the world over. if *they* subscribe to the same tight-binding mantra, you've got a real problem on your hands every time you want to roll out a change. sure, generating the new data entities might be as easy as drawing a diagram or two, then generating the code, then rebuilding the data layer, then modifying the business layer, and then updating the client layer (see, how bad is that?). but getting all your customers to upgrade in a timely way. and doing it without killing off existing clients is even more exciting.
of course, Web-based apps that use HTML/CSS/Javascript and follow a REST-like architecture for implementation have an easier time of it all. first, there is no tight-binding at the client level. th payload can be an argument collection (HTML FORM POSTING) or a single object (XML or binary file upload). second, the actual payloads passed back and forth can be controlled using metadata (HTTP Headers Content-Type and Accept) that can make it easy for existing clients to continue to use 'old' versions of the system while new clients can safely upgrade. often these applications deliver the client code themselves via HTML pages so upgrades are much easier to deliver to users.
finally, one of the key tenets of the REST architectural style is to introduce a set of abstractions that make it much safer (not easier) to build applications that live for a long time on a widely distributed network where application owners do not always control all aspects of the system. REST offers methodology for abstracting function calls, abstracting server resources, abstracting data-passing/encoding, and abstracting data resources and their location. by following these practices, it's much easier to optimize both application/network and user experiences. and that's the important stuff. developers might have to work hard. work hard to understand these patterns. work hard to build applications that follow these prescriptions. work hard to grow and maintain these implementations over time. but that's their job, isn't it?