Building A Better Server Control Experience, Part 3

Building a Better Server Control Experience, Part 3
Architecting For Simplicity: Don't Build It For Yourself

I'm in the middle of completing a round of upgrades to Interscape's website, and I thought I'd take a second to cover something I've been wanting to talk about for a while. My first two posts in this series have received a very positive response. So, I decided to put off talking about documentation as I said earlier, and focus on another, more important topic.

First off, before I go any further, I'd like to apologize if I may have been a bit obtuse regarding GenX.NET in the past. When you only have one product on the market, you tend not to want to give too much away, especially when your competition might work faster than you and beat you to the punch. When I came out with GenX.NET 1.0 a little over a year ago, it was the first of it's kind to translate data to Excel through managed code. Inside 30 days we had a competitor. Inside of 120 we had 3. So there is always pressure from the marketplace to innovate and stay ahead.

Hey Rob, why don't you shut up about GenX.NET already? No one really cares!
Well, that is a valid point, to be sure, and not the first time I've heard this sentiment. I'd like to dissect that statement and bring it to it's true point, which really bothers me. No one cares about simplicity. Sure, we all spout off about how the next big thing is easy to use, blah blah blah. But do our actions reflect what rolls out of our mouths? Not usually. Several times though the course of my comparatively brief professional programming career, I've been forced to deal with projects I inherited where the programmer before me felt the need to prove himself by taking a relatively simple concept and complicating the hell out of it for no apparent reason.

Nothing frustrates me more. I don't think like most people do. That doesn't make me any better a person or programmer than anyone else, I just think differently. I was fortunate enough in elementary school to be pulled out of my regular classes once a week for a special class called “ELP“, which was short for “Extended Learning Program“. In that class, they had a whole different way of teaching. The focus wasn't on cramming your head with useless knowledge, the focus was on teaching you how to reason, analyze, think critically, and approach problems from different angles; basically How to learn, not WHAT to learn. Many of you are parents out there. If your kid's school has a program like this, do whatever it takes to get 'em in there. It's the best thing you could possibly do for them.

It was through these skills that I taught myself how to write computer programs, starting around age 8. I've never taken any programming classes, and have always experimented to find out what works and what doesn't. While I feel that I understand many programming concepts better than most, this methodology takes me 4-5 times longer to crank out code. So, before GenX.NET 3.0, I had never used any design patterns, because I felt that they are too often misused. I still think even today that most code out there today just plain sucks. It's over-anal-yzed, overengineered, and overcomplicated. And many times, abstracting the code only makes it exponentially difficult to understand. If I can't understand code, I can't learn from it. If I can't learn from it, I won't waste my time with it.

Using Complexity to Design for Simplicity
DTS is not a new concept, and neither is the Provider Model. What is a relatively new concept is using complexity to design for simplicity. If I were giving this talk in public, at this point I would expect a ton of blank stares. “But Robert,” the guy in the first seat in the second row would ask, “How can a complex system make something simpler?” Well, second row guy, I'm glad you asked. Complex systems can make something simpler if you don't design it for your own use. You use a perfect example of this concept every day. It's called the .NET Framework. Sure Microsoft uses it internally, but it wasn't designed for them. It was designed for you, which by default makes it the perfect fit for them. My controls are the same way. Sure, we wrote them because we need them too, but we designed them because we wouldn't be the ones to implement them. Our end users wouldn't have the benefit of my hundreds of hours of work on this system to be able to reason our bigs and API design. We had to make it dirt simple, so that you looked at it, and you just got it. While I would love to have daily one-on-one interaction with my customers, I'd just as soon they not have to call me because they can't understand some obscure part of my API.

So, how can you make sure they'll “get” it? By assuming that they won't. I don't mean, be an ignorant, pompous jerk and treat your end user like they're a moron. OK, well you can try that if you want, but I don't recommend it. The whole reason nerds get a bad name is because they can't “make it work” for non-nerds. Someone comes to them and says “This control doesn't work”, and the programmer goes,”Ugh, let me see it. *types on keyboard really fast* All you have to do is take this code and register it here, and these simple 40 lines of code to wire it up, add 7 user controls to the page, make sure these 3 assemblies are registered in the GAC, and you're all done. See isn't that simple?”

So, you quasi-solved the problem, the end user still has no idea what the heck you just did, and you are still no closer to a true solution. Now, that's great if you're only doing that for a maximum of 10 people. But what happens when you have 100 users? 1000? 10,000? Do you REALLY have the money to provide support for all those customers because you didn't think every detail through, or because you were under a deadline and had to cut corners? Probably not. I know I sure as heck don't, so I'd rather spend 30 hours architecting it properly than 3,000 hours supporting a bad architecture.

So, in Part 1, I talked about coding for the requirements. Well, one of the requirements for GenX.NET in Version 3 was that the API we exposed to developers would remain relatively unchanged from Version 2. While I think it's really admirable that Microsoft works so hard to make sure that there are no breaking changes, I don't operate that way. I fully expect that coding changes are going to have to be made to take advantage of new features, and I don't make any bones about the fact that API may change between major releases. The difference here is that I wanted to keep the simplicity of the API, while building the best new architecture possible.

Another goal was to architect the system in such a way that I would be able to put the providers in a separate assembly, and release updates to the formatting or output implementations without having to release a whole new assembly. Unfortunately, that didn't happen in this release, but Version 3.1 will build on some of the provider referencing concepts that Rob Howard helped pioneer with ASP.NET Forums 2.0 and Whidbey to make it a reality. With this architecture modification will come the capabilities necessary to make ScrollingGridPlus!, the ScrollingGrid / GenX.NET hybrid, exponentially easier to accomplish. Combined with our next component, currently dubbed “Introspector.NET”, you'll be able to export the contents of a DataGrid without writing any extra code.

But I digress. The point was to make a complex architecture that was easy to understand, and even easier to use. The overall architecture of the system is best illustrated in this diagram:

As you can see, the architecture is very simple. It doesn't need to be any more complicated than this. I don't even really think it needs explanation, but I have one I will more than likely discuss later. I came up with this architecture after seeing the Factory design pattern in a Wrox book on VB.NET Class Design. It wasn't until 6 months later, having nearly completed the architecture, did I find out that Microsoft was baking a similar concept into nearly every aspect of .NET. For me, GenX.NET now held new significance. Not only was the architectural model proven to be solid (if Microsoft is doing it, it stands a good chance of being successful), but we also had to be a rock-solid example of what is coming next year. I know I'm not the only person who looks at code from a simplistic perspective, and the leap into these kind of architectures is a big one. If we had a year to make the leap before Whidbey, then GenX.NET would be a good start.

So now, having seen all this, you're probably thinking, “But Rob, GenX.NET is an API not a server control.” And you'd be correct. Version 3.0 is an API. Version 3.1 however, will have full VS.NET design-time support, including editors for linking up to functions that return ADO.NET objects, and the possibility of a visual style designer. You'll be able to drag-and-drop GenX.NET from the toolbox, and configure it without writing any code (sound familiar?).

None of these things would have been possible if we had not Coded for the Requirements, Minded The Details, and Designed for Simplicity. Understanding these concepts is a prerequisite for making the leap from writing nifty conceptual code to designing solid solutions. Now if you'll excuse me, I've got to put my money where my mouth is, and finish putting these concepts into practice for ScrollingGrid.