Jeff's Blog

This is a little interruption to cover something that's on my mind a lot lately. One of the more interesting attributes of a truly good web developer is design based on what's possible. The web is a much more fickle place than a database. There are hard predictable albeit often confounding reasons that govern the way databases work. The web, while still mostly governed by reason and known rules of invocation, has an edge of unpredictability. Partly this is due to differing interpretations of standards "compliance" helped along for better or worse with Microsoft's strong tradition of backward compatibility, but partly this is due to number of layers that exist between users and the systems that they are working against.

Think about a group of dominoes standing on edge all spaced perfectly to create a chain reaction of falling down when the one is knocked done. If you're like me you've tinkered with making these elaborate chains of dominoes to both test your ability to plan and execute as well as just the pure fun of seeing things fall. Setting up dominoes to be knocked down can become a pretty elaborate task, but as long as you can see all of the dominoes and insert appropriate checks to prevent unintended consequences it's not terribly hard, just tedious. But what happens if you're not able to see certain dominoes, or stretches through which the dominoes will pass. How do insure there are proper checks, how do you verify the spacing to insure that there won't be a break in your chain. What about possible recovery plans in case there is a collapse, or a break in your chain?

The trouble with the web is that there is so much that is out of your hands. On the one hand, it's a fantastic benefit that someone has worked out the very complex issues of network communication; on the other hand you have to work with its inherent limitations. This type of uncertainty often leads to prototype heavy architecture, or at least is should. Sure you can take applied knowledge to a new problem and do a fair amount of traditional upfront architecture, but in reality web development for better or worse often starts at the level of the Wire Frame or the Mocked up website.

You can see this effect in the current blog series that I'm working on, where I'll be somewhat unconcerned with nailing down the absolutes of a pattern, and more interested in getting something I can work with in a real User Case to fully flesh out the design. There's definitely an air of XP to it, but it's not pure XP. I like test driven, and XP, but I think it's sometimes slower than it needs to be. There are some things you just know as a developer, especially after a few years of coding, so there are just going to be those things where it's better to code an unit test in a more fluid manner than is often implied by XP.

The idea is basically to start with what can be done and code/design back to how it should be done. This approach can influence every layer of the application, from how domain properties are grouped to the thickness and groupings of the BLL, to the type of Data access Layer that best fits the UI. And as much as this goes against the vast majority of literature on good design, I does work, most of the time.

The key to this equation is the disposability of the web. A website can become out-dated in 2 years, and borderline obsolete in three. Sure good Designer work can buy you a little more life time, but the User facing portion of a website has a very short shelf life. And while the backend can certainly outlast the thrashing of UI level intricacies, there's a lot of pressure on back ends of websites to implement the latest and greatest pattern from the ever churning best practices mill.

The thing that strikes me as the good in this approach is the focus on possibility and the built in recognition that flexibility is paramount to success, but the negatives are vast and deep. The primary among these is the combination of a company's and a developer's ability to stay committed to a project. If they are committed, the developer can fully evolve their creation into a healthy maintainable state, but as I'm sure you know, all too often, the effort peters out long before the project reaches any sort of maturity. Either the customer needs it yesterday, or the developer gets feed up the management BS that stands between him/her and doing things right.

So I guess I'm saying that I'm dubious about the WWW approach to design, but that I think that it's been a very useful contributor the world of enterprise application design, and that I recognize that the things that I do on my way to an answer may not always be the most intuitive, but they are part of a honed process of randomness that is web development. Just a thought…