MyPicasaPictures Part 4: Smart Client Software Factory — a deeper look

Having determined that of all the Patterns and Practices guidance, the SCSF is likely the one with the most to offer my project, I decided to see what following the Getting Started steps would get me.

And just my luck, I can’t even get past the first steps — to create a Hello Word application, I need to be able to select from the “Guidance Packages Project” in Visual Studio, but it appears they didn’t even get installed.  I’ve run the SCSF (May 2007) installer twice and selected everything, but still it doesn’t add any entries to the New Project dialog.

What’s a little disturbing is that when I started to peruse the discussions to see if anyone else had run into this, the detailed steps that people had to go through to troubleshoot problems with this guidance were shocking (see this thread, for example).

I really didn’t expect this “factory” to be this complex — I was hoping for a library of code and simple steps to piece different bits together.  What I seem to have gotten instead is another “learning opportunity”, much like the MCML rabbit hole — some limited set of benefits that’s masked by a steep up-front learning curve, and that only benefits your use of that proprietary set of tools.

Does anyone ever just try to create a set of code snippets or object libraries?  Why does everything require learning a whole new development paradigm, and some new hierarchy of newly-overloaded terminology that doesn’t relate to any of the stuff upon which it purports to build?


Dependency Checker: decoupled from install?

Wow, so I decided to go right back to the beginning, and see if there were any hidden steps I missed the first couple of times.  It turns out that, without making too much of a big deal of it, the SCSF team has written a separate downloadable tool that checks for all the required and “optional” (?) dependencies [who ever heard of an optional dependency?  That’s a new one on me].  After all this time, I’ve come to expect that the installer for the program I’m after would check those dependencies as a first step, and would tell me to go get the pieces I’m missing if it detects that it won’t be able to work if it installs.

No, for whatever reason these guys seem to have decided that they want their end users to “educate” themselves on what it really means to use their guidance, so they seem to have intentionally left at least one land mine in place for most newbies to trip over.  I dunno, but if most .NET applications can test for the presence of the required .NET Framework (and halt the install if it’s missing), how much harder could it possibly be to add this dependency checker code as a pre-install step and direct users to the pieces they’re missing?

This reminds me of the days when you downloaded Eudora or Mosaic to “access the Internet”, and then later learned that you needed to download Trumpet Winsock or some other TCP/IP stack before they’d work.

YAFR (Yet Another Freakin Runtime): Guidance Automation Extensions

Well, so it looks like I’m missing something called the “Guidance Automation Extensions“, which sound reminiscent of the Office PIAs — yet another set of libraries that are necessary before the specialized development software will ever work.  Why does everyone seem to want to carve off a set of “foundation libraries”, rather than just include them in their software package itself?  Why do these scenarios inevitably require the end user to become an expert in the internals of the application, rather than just make it as easy as possible to get up and running in one step?

Maybe it’s the Micro-skeptic in me, seeing how often people at Microsoft fooled themselves into thinking that *their* little piece of the platform was the *most* important thing around, and why *shouldn’t* our users spend some time learning how our stuff is supposed to be used?  It’s just such ridiculous arrogance, and in a lot of ways, I suspect it stems from the hiring process itself — hire these geeks straight out of college (with no previous real-world experience or humility i.e. ever failed at anything in their lives), tell them they’re the absolute best of the best, and then set them loose on a project.  Of *course* they’re going to believe that whatever comes from their mind is the product of god.

Now, after installing the so-called “GAX”, re-running the SCSF installer enables me to select the “Automated Guidance” selection (which had been greyed out before –  which in other installers simply means that you’ve already installed those bits, and don’t need to worry about them again).

Why CAB in the first place?

However, this is just the beginning of the confusion – for a tool that’s supposed to make it easy to build a well-patterned application, the discussions and blogs around SCSF make it clear that this is no library – this is yet another “only once you’re expert with it should you use it” tool.

Bil Simser says, “The point is that SCSF made me more efficient in how I could leverage CAB, just like ReSharper makes me a more efficient developer when I do refactorings.”  However, what he pointedly fails to say is that SCSF makes him more efficient as a developer.  The debate assumes that you have already determined you must use CAB, and once you’ve fallen down that crevasse, what’s the best way to crawl back out?

I guess I need to take this one step further back, and understand the value of CAB to my current application development needs.  Until that time, I’m going to be very skeptical of having to learn the internal logic and complexity of yet another proprietary tool, and be very resistant to investing the time needed to learn enough to make it useful.

A little earlier in his blog, Bil Simser has this to say:

I’ll be the first to admit that CAB is complex. EntLib is large. There is a lot there. As Chris said this morning in what I think was an excellent response to the entire discussion, CAB for example is not just about building maintainable WinForm apps. I like CAB as it gives me a bunch of things and they all work together in a fairly harmonious way. EventBroker is a nice way to message between views and keeping the views separate; CommandHandlers allow me to hook up UI elements indirectly to code to execute them; the ActionCatalog let’s me security trim my commands (and in turn my UI); and the implementation of the MVP pattern using views lets me write presenter tests and keep my UI thin. This all makes me feel good. Did it take me a while to get here? Absolutely. I’ve spent the better part of a year learning CAB, EntLib, ObjectBuilder, WorkItems, and all that jargon but it’s no different than learning a dozen different 3rd party libraries. I simply chose the MS path because it was there and everything was in one neat package. If you packaged up Castle, NHibernate, StructureMap, and others together in a single package maybe I would have chosen that path (and is there really two different paths here? I use both tools together anyways).

Yipes!  Better part of a year?  [And that’s not even counting the SCSF learning curve!]

Not to mention that even the experts wouldn’t want to try to explain it in a short amount of time:

Unfortunately [Entlib/CAB is] not something I could introduce at a conference or User Group session and describe the entire stack in an hour, so I tend to avoid showing off applications and concepts using it as it just turns into a discussion of what (SmartPart) means instead of the main goal like describing MVP which I can do with my own code.

And the promise that even with all of what’s bundled into Entlib and CAB, you could still find yourself dragging in all sorts of other crap:

Eventually I could have a really ugly monster on my hands with copies of Castle, StructureMap, CAB, EntLib, NHibernate, log4net, and who knows what else all living (hopefully) together in happy existence. I don’t want that.

More words to give me pause, from Chris Holmes:

I’ll also say this about ObjectBuilder : I agree with Jeremy; I wouldn’t use it on its own. It’s hideous. It is overly complicated, undocumented and cumbersome. It is the worst part of EntLib and CAB. Fortunately, when using EntLib and CAB I don’t have to manipulate ObjectBuilder. If I did, I’d have abandon both tools a long time ago.

So we come to this question: If I don’t like ObjectBuilder, then why am I using CAB or EntLib?

Now, some people might say “that’s Big Design Up Front”. I’d argue otherwise. Our ultimate goal was testability. We wanted to adopt an MVP architecture so that we could have a very testable UI layer. We wanted automated tested; we wanted automated builds; we wanted the confidence that comes from having a vast suite of unit tests; we wanted the confidence to refactor our code without fear of breaking a tightly coupled system. So our goal was not to have “nifty tools”, but to have a framework to build upon that would give us our ultimate goal: a testable UI layer that we all would have confidence in.

My assumption was that [rolling my own code] would take a considerable amount of time (and not as BDUF; but as time spent building the pieces when necessary. The bottom line is, it still takes time, no matter how you allocate it, and I wasn’t certain how much). That assumption was probably unfortunately influenced by looking at the CAB as a frame of reference and saying, “Holy cow, there’s a lot there…”

So we went with CAB. The idea was that we thought it would help us get out of the gate faster. I thought it would take less time to grok the CAB and make use of it than roll my own code. Maybe that was an error in judgment. It’s certainly possible, I am human and very flawed. But I did manage to grok the CAB pretty fast compared to other adopters, so it seemed like a good decision to me at the time.

I chose CAB because I thought it was the best solution at the time, given everything I knew about software design and weighing all of the other factors involved. I might make a different decision today, given the amount of knowledge I’ve accumulated and the tools that have emerged. I might do just what Jeremy and Oren propose, and grab an IoC tool like Castle and grow my own solutions as necessary.

SCSF, CAB & Entlib: just not ready for the Media Center developer crowd

While having an IM conversation with one of my respected colleagues today, I complained about all the time I was investing in learning about yet another framework:

I just dove deep into the CAB/SCSF/MVC-P crevasse, and it’s amazing how much of learning the bit you need depends on learning the next-layer-down foundational piece – and how many f’n foundational layers there are once you start looking closely.

The thing that J.D. Meier & co did well was provide some automated “wizards” that setup all the skeleton code once you know which pattern you want to use.

The part they addressed poorly is to provide any “entry-level” patterns for weekend hackers like me – everything is all about “steep learning curve, big architecture, lots of pieces to re-use once you figure out the puzzle up front”.  I’m not even convinced I ever want to do this kind of project again, and the amount of setup to even try it is making it less likely I’ll even do it once.

It strikes me that if I were to adopt one of these mammoth frameworks for the MyPicasaPictures project, the only advantage to the pre-defined pieces that are available to fire up at will is that other people (already familiar with the same framework) would have an easier to finding a customizing the pieces they wanted to bolt into.

For the rest of the Media Center community, if they wanted to extend the application or plug in a new module, they’d be forced to suffer the same learning curve as I’m facing right now.  This is not a community that I’d expect to be familiar with these enterprise development frameworks, nor do I feel particularly cruel enough to try to foist such a hairball upon them.

Fascinating quote to end this research vein with:

The end result is that this [anti-Agile programming] architect and I could not possibly coexist on the same project.  My longstanding opinion that traditional architects are useless if not downright harmful remains completely intact.  I guess you wouldn’t be slightly surprised to find out this guy is a big proponent of software factories as well.  Of course, this guy had more people in his talks and better evaluations than me, so what do I know?

If his description is any indication, and if I assume the likelihood that factories-based development suits the Media Center developer crowd is slim to none, then let’s just forget about the whole idea of using factories/frameworks for VMC-oriented development.



Next stop: back to the drawing board.  Perhaps I’ll work on a few crisp use cases to anchor the development of one or more rounds of Agile-esque coding.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s