A Train of Thought – May 21-28, 2007 Edition

Just some quick things I’ve jotted down over the last week and change.  But first, sigh…

The CAB + P&P Brouhaha

The bit of nastiness, or perceived nastiness, over the CAB and Patterns and Practices recent blogging has got to stop so we can get back to what should be a very valuable discussion.  Email and blog posts just aren’t a great way to have an effective conversation.  Negative vibes just come through far too easily without actual human contact.  Body language and face to face contact would have stopped the unpleasantness in its tracks.  The role of the Patterns and Practices team and the appropriateness of the Composite Application Block are very useful discussions to have.  We need to be able to disagree, and even criticize, without getting personal.

Dredging up six year old newsgroup posts to try to make one of the participants look bad is nothing but childish.  My God, 6 years ago *I* thought VB6 was the single best language on Earth, C++ developers must all be gods, Java developers were wussies for trying to abstract the database away, all data access should be through stored procedures, and this new UML thing was the best possible way to work through a design before starting code.

Everyone, including me, repeat after me:

  • I am not my code.  A criticism of my code doesn’t have to be a personal attack on me.
  • I am not the tools that I use.  A criticism of my tools shouldn’t be construed as a personal attack on me.
  • I am not the programming language that I use

Let’s remember the lossiness of communication on the blogosphere and keep a thicker skin.

In defense of CAB

Actually, the very fact that so many smart people (Sam, Chris Holmes, and Bil Simser) came out in favor of the CAB *is* a big endorsement of its capabilities and usefulness — so what do I know?

CAB and the Roll Your Own vs. Off the Shelf vs. Not using a framework at all conversation

Part of the blogging going on at the moment about the CAB and P&P team is around the neverending question to use a framework off the shelf or roll you own.  Let’s make a few things very clear, I don’t use the CAB, I do use MVP patterns quite successfully with a high degree of test automation, and I do not have to roll my own CAB to do so.  When I say “grow your own,” I really do mean to simply grow what you need — when you need it, as you need it.  For my apps, the CAB is severe overkill.  The problems that the CAB solves don’t seem to be particularly hard to me anyway (can someone please write in and give an example of something hard that they think the CAB makes easy?  Seriously, I’m willing to be wrong about this).

Somebody quizzed Ayende on why he thinks it’s okay to rewrite the CAB but NHibernate is okay to use right off the shelf.  That’s an easy one for me.  Tools that amount to “just something that you use” like NHibernate, or log4net (but I’m not letting them off the hook for the versioning and breaking API hell a couple years ago) are not intrusive.  You just use them when you need the service that they provide.  Tools and frameworks that are intrusive into your code, or even worse, require you to wrap your application around their opinionated structure are a different story altogether.  I’m thinking about frameworks like NEO, the current version of the Entity Framework (but they’ve promised to make the intrusiveness optional in a later release), CSLA.Net, and the CAB.  I’m not saying that I wouldn’t ever use these tools, just that the bar for using them is much higher in my mind than something like NHibernate.  If I hit a project where CAB does exactly what I want it to do, and learning and applying it is faster than building my own, I’ll do it (just as soon as I rip out ObjectBuilder & replace it with StructureMap ;-) ).

 

Patterns & Practices

For the record,here’s my description of the P&P team (emphasis added for here, and some grammar corrected):

The Patterns and Practices team is a little beacon of Agile light in the Microsoft sea.  Yes I do think that many of the P&P solutions aren’t really all that great, but I want the P&P team to succeed.  A strong, visible P&P team benefits us greatly.  The P&P team is making it easier for me to use the techniques like Dependency Injection and TDD on client engagements.  That’s a win.

I know they’re Agile, and I love that, but it’s perfectly acceptable, and even desirable, to critique their work products.  There’s no way we should just accept anything they, or anyone else for that matter, create without question.  I actually won’t back down too far over the “working in a vacuum” remark.  They’re a centralized framework team, and that’s the trickiest type of development to get right.  They’re not dogfooding their own stuff inside of a real application project.  Yeah, they get feedback from clients, but it’s not the same.  In general, I think splitting application teams from the framework builders is always dangerous.  It’s dangerous inside of a single enterprise, and even more so for an entire development community.  No matter how talented the P&P team is, and they certainly are, they’re working at a disadvantage compared to someone who’s harvesting a framework.

I do wish the P&P team would be a little more receptive to OSS tooling, or at least talk about OSS tools on their website.  Especially when they’re writing tools and using techniques pioneered by OSS tools or other development communities that predate their own work.  I think it’s great that they adopted Dependency Injection and publicized the pattern, but it would be nice if they’d at least admit that they didn’t invent the concept and mention the other tools. 

No, I don’t think I can build a better CAB

Not going to happen, and it’s not worth the time to even try.  Yes, if you ask me in an unguarded moment I might admit that I’m cocky enough to think that I could build a better CAB, but it’s not high on my list of priorities.  My argument against using the CAB revolves around the idea that I do not need any kind of elaborate framework for WinForms development.  The easy stuff is easy, and the hard stuff tends to be very specific to each application.  I want the semantics of the screen navigation and coordination to be expressed in terms of the application domain, not in language like “SmartParts.”

But if I were to even flirt with the idea of “ok smart guy, let’s see you do something better…” it would be with IronRuby when that becomes a tad more mature (like, actually released as a download) — and that’s mostly to have a real thing to do with Ruby.  I think somebody, either one of us or the P&P team, could make a CAB-killer by using either embedded DSL’s in Ruby or some of the more advanced C# 3 features.

And if it did come down to an attempt to write a better CAB, I don’t see that as being even slightly irresponsible.  The CAB isn’t the penultimate tool, and the P&P team doesn’t have a complete monopoly on innovation.  Diversity is good.  Innovation is good.  I don’t have to fall in line and use whatever technique or tool MS spits out if I think there’s a better way.

I do think that the contrib projects that Bil Simser was announcing for CAB & EntLib are exactly the right thing to do for these tools, and I was glad to see it.

 

That’s fine for you, but what about my guys…

In the whole CAB thing I heard several remarks that basically went:  “that’s fine for Ayende’s and Jeremy’s, but average developers can’t roll their own.”  The assumption being that developers that aren’t talented or experienced enough to do Model View Presenter are going to be able to use the CAB effectively.  Two points:

  1. If you understand the underlying patterns, you are much better equipped to bypass the CAB
  2. You’ll be much more effective using the CAB if you understand the underlying patterns first.  Tools are generally going to be easier to use when you understand why the tools are built the way that they are and what they’re trying to accomplish.

In the end, you better be studying the patterns regardless.  As soon as I get over a nasty hump early this week, I’ll get cracking on my “Build your own CAB” series again to help in this regard.

 

Automated tests are like push pins

You know, some code is really easy, and it’s awfully tempting to forgo testing that code.  It’s still a mistake, because a test does more than check that the code works as you write the code.  It also pins down that code.  An automated test puts a stake in the ground that says “this should work like that, and if it stops working like that, I’m gonna throw a fit.”  A set of automated tests lets me turn my back on a piece of code with the confidence that comes from knowing that anything that the behavior of my code won’t get hosed by other changes without some warning.

 

First, finish what you started

Done, done, done.  I think you should take the attitude as a team that you get zero points for any work until you have something that’s completely ready to ship.  That means working a feature from a gleam in the customer’s eyes all the way through deployment scripts before you move on to the next piece of work.  Otherwise you just have two features in an intermediate stage with nothing ready to ship.  More importantly for this little rant, I want to finish out a user story at least to the point where I have those automated tests to act as a push pin before something else comes along and destabilizes the previous code.  Life’s hard enough without getting screwed by somebody else’s work.

 

The Power of Osmotic Information

At the DevTeach Pair Programming session the presenters showed some pictures of their work environment.  Other than substituting Space Invaders wall decorations for Jeffrey Palermo’s gigantic Texas A&M banner (shudder, I’m a Rice grad), it looked a lot like our old office in Austin.  Basically, one long table in the center of a single room with everyone, and I do mean everyone, sitting around the table.  All conversations happen in the room.  Somebody across the room gasped “that’s not what Joel says!”  To which I immediately yelled out “Joel is wrong!”  If you haven’t seen it, Joel Spolsky published a checklist of his 12 questions that any good team in the Joel universe needs to answer in the affirmative.  One of his 12 points is that each developer gets his own office with a closed door so they can work in blissful silence without distraction.

The noise isn’t really that bad.  You’re concentrating on your work and/or your pair.  It’s really easy to block out other people when you need to.  Besides, it’s just much more fun than the utter isolation of cubes or offices.

 

Jeremy’s take on the Joel Test

Just for fun, here’s my review of his list:

 

  1. Do you use source control? — Oh lord, I hope so.  That’s right up there with wearing sunscreen out to the beach
  2. Can you make a build in one step? — 2 for 2.  Absolutely necessary for frictionless work.
  3. Do you make daily builds? — Not good enough.  Daily builds are far better than no builds, but I’d rather have fullblown Continuous Integration going far beyond a simple daily compile.  Better traceability, causality, feedback
  4. Do you have a bug database? — Yes, but you *can* do it in a very lightweight manner 
  5. Do you fix bugs before writing new code? — Amen.  See the above on “finish what you started”
  6. Do you have an up-to-date schedule? — You better not go into cruise on this one.  Planning never stops because you’re learning things about the work as you go and priorities will change
  7. Do you have a spec? — I agree in principle (surprise), but I disagree with Joel on the form of those specifications.  Requirements?  Heck, yes.  Word doc, hell no!  More on this later.
  8. Do programmers have quiet working conditions? — See the osmotic information section.  This is the wrong question.  Do the programmers have a comfortable working area that facilitates collaboration?
  9. Do you use the best tools money can buy? — Yeah, but you know that I think the answer is often OSS tools, so it’s not just the money.  I will not code without ReSharper, naked VS.Net is just too painful.
  10. Do you have testers? — I think it’s absolutely insane how many organizations and teams do not have embedded testers on the development team.  It’s irresponsible.  I’d go farther than Joel.  I want the testers completely embedded into the development process, not just swooping in at the end of the waterfall.
  11. Do new candidates write code during their interview? — That’s an awfully fast way to separate wheat from chaff
  12. Do you do hallway usability testing? — No opinion, as long as I have plenty of user feedback, I’m happy.

Nevermind, I agree with more of it than I thought.  I think he missed some big things (effective test automation, organized/formalized iteration management, lots of feedback loops, customer involvement), but I’m getting drowsy and I just don’t have the requisite ‘nads to do the “Jeremy Test.”

My advice vis a vis the Joel Test?  Again, there are no smart guys, only us.  Make up your own mind and fit your practices to your project.  The smartest thing you can probably do is just to constantly ask yourselves “if I could make one single improvement, what would it be?”

 

Important Advice

To all you youngsters out there, if anyone ever offers to let you check in first and then handle any ensuing merge conflicts, the answer is always YES! 

 

It sucks being the one truck guy

You know that awful phrase “what if you get hit by a bus, what do we do?”  Right now on my project I’m the “one truck guy.”  It sucks.  I’m trying hard to offload some stuff and spread the understanding of the system, but it takes time.  I’ve got a team now (or I’ve got a handful of people invested enough in the project to make a standup worthwhile) , and it’s actually a cool thing just to have a team instead of flying solo, but everyone else has a narrow purview of the work. 

Specialization sucks.  Specialists can barely talk to one another.  Teams with redundancy in skills and knowledge are easier to work in, and work much more collaboratively, IMHO.

 

Whatever it is, do it together

Look, I like to put the headphones on and go heads down as much as the next person.  I’m one of those people who likes complete quiet to concentrate fully, but that’s a local optimization for my personal productivity — and we know that local optimizations are a fallacy.  No matter what the activity, if you’re doing something that creates knowledge, be it design, API, build, or analysis knowledge, do the work together in a collaborative manner.  Yes, you’re using more people to perform that particular task, but you might be saving much more time later because the participants have more knowledge by participating that they could ever glean after the fact from emails or specifications.

 

CodePlex getting Subverted

I think the recently announced Subversion support on CodePlex is a great thing.  I’ve got to run it by Jeffrey & Josh first, but I’m going to think pretty seriously about moving StructureMap off of SourceForge and over to CodePlex.  I’m not that wild about SourceForge.  It has everything you could ever possibly want, but it just feels too Unix-ey to me.

Ok, nevermind.  I went and researched it a bit.  The SVN support sounds a little dodgy, and CodePlex feels slow and clunky to me (not that SourceForge is all roses, but it’s familiar).  I’ll wait and see.

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://community.hdri.net/blogs/chads_blog cmyers

    Tom,

    Cool reply, thanks.

    Like I said, I ended up not using it, so that was just my ‘evaluation’ experiences. Perhaps if I had delved deeper, it would’ve become more clear.

    I’m sure it’s come a long way since I last looked at it which was some time ago (2+ years).

    Taking away everything else I said, there might still be one valid criticism left:

    It wasn’t immediately obvious how to quickly use just the pieces I wanted to use.

    Maybe that’s gotten better, but with log4net, it’s stupidly simple and drop-and-go. EntLib seemed to be a big 800 pound Gorilla that was bigger than the entire app I was building. Something in there seemed wrong to me, but perhaps it was just my perception.

  • http://blogs.msdn.com/tomholl Tom Hollander

    cmyers: I appreciate any constructive criticism on EntLib and anything else, but I don’t agree with some of your statements about the Logging Application Block so I’d like to probe a little deeper to understand your experience a bit better.

    “EntLib was big time in-for-a-penny-in-for-a-pound. You couldn’t just use logging because you got everything in a 50KB XML configuration file whether you used it or not. ”

    We did work hard to decouple all of the blocks from one another as much as possible. The only cross-block dependencies are in optional providers that are factored into their own assemblies. The only dependencies that every block has are to the Common and ObjectBuilder assemblies (which you need to reference, but you don’t really need to think about). For all practical purposes you do need to have a configuration file for some blocks (including Logging, but not really for Validation, Data or Policy Injection). However all of the information in the configuration file should be “useful” in the context of your app – for example the logging configuration is used to specify which messages go to which Trace Listeners.

    “The logging code was very verbose and cumbersome and would’ve involved a lot of retooling in our app. IIRC, some if it used attributes that would’ve imposed code changes in many places to accommodate EntLib’s pre-disposed design constraints.”

    I don’t believe this is true. The majority of your logging needs can be met with a single line of code along the lines of Logger.Write(“Hello”, “Category”);. Even when using the more advanced options such as custom LogEntry classes, Extended Properties or Tracing the surface area of the API is very small. There aren’t any attributes used in this block at all.

    Again, don’t get me wrong here – I appreciate the dialog and I’m not trying to be defensive here – I just don’t understand the criticism here so it will be hard for the team to act on it.

    Tom

  • http://codebetter.com/blogs/sam.gentile Sam Gentile

    Nice job on this post Jeremy

  • http://www.articlepark.org/ Tony

    Your this article is very good

  • http://www.webgambit.com Karthik

    Agreed with most of what you said, but I still like having my own office/cube as a developer.

    I’ve done the whole “open environment” thing and I’ve found that while it works well for some people it can be very distracting for others.

  • http://wundasworld.blogspot.com Wendy

    Great post Jeremy!

    I agree, rolling your own is sometimes the best way before using another framework — you appreciate the patterns and can actually understand what they do.

    As far as Joel goes, its not the validity of the questions, but whether you can truly know anything with 12 set questions. If a company doesn’t have continuous integration, but wants to try, do you have the skills to bring them there? Is it a better than a company that has the list but missing stakeholders, has red tape blocking issues, a really boring project, an unhappy team, etc… Each company is different and the questions you ask is really based on the context of the company and what you think you can make of the environment.

  • http://scourtrille.wordpress.com Shane Courtrille

    Two points…

    1. After all the back and forth stuff going on I decided to give CAB a try. I downloaded it and played with it a bit. To be honest I didn’t spend the time to implement a full mini project in it. The problem was after an hour or two of looking at the documentation it just seemed like it was such a massive overkill to me. I’d love to hear someone give a reason why they use the CAB and how it helped save them a bunch of time.

    2. One of the things I’ve found a bit strange was the entire “My guys” argument. So you’re telling me you can teach your guys the entire CAB but the patterns that make it up are too complex for them? I for one don’t buy it.. and more importantly let’s assume CAB gets to the point where it was true. At that point “your guys” are still missing out on an entire world of techniques that they can use in every layer of their code.

  • http://community.hdri.net/blogs/chads_blog cmyers

    Admittedly, I haven’t looked hard at EntLib in over a year, but the last time I checked in, it seemed to have gotten even bigger and more obtrusive, so I don’t have a good reason to believe it got smaller.

    I remember we were looking to add instrumentation and logging to our app (another Big, Obtrusive Framework that has caused lots of angst and regret on the part of me and other developers who now have to maintain it) and EntLib was big time in-for-a-penny-in-for-a-pound. You couldn’t just use logging because you got everything in a 50KB XML configuration file whether you used it or not. The logging code was very verbose and cumbersome and would’ve involved a lot of retooling in our app. IIRC, some if it used attributes that would’ve imposed code changes in many places to accommodate EntLib’s pre-disposed design constraints.

    Log4net, OTOH, was simple, lightweight, and was a drop-in and involved minimal code changes and even less configuration changes.

    Side note: Spring.NET is a Big Framework that has tons of features-i-find-it-hard-to-believe-anyone-asked-for, but at least I don’t see them and know about them because they require no configuration. I seem to recall that EntLib required tons of configSections and other noise that complete dominated our otherwise simple and lean app config files.

  • http://blogs.msdn.com/gblock Glenn Block

    Just out of curiosity, how does Entlib force you to adopt any full way of thinking? Entlib blocks are cross-cutting pieces, you use them where you want to and don’t where you don’t. Also with the provider model, you can extend each of the blocks with your own implementation.

    I agree that CAB does force you to adopt our way of thinking, and SCSF even more so (that is to the degree you use it), but how Entlib?

  • http://blogs.msdn.com/gblock Glenn Block

    Thanks Jeremy. I respect your and Oren’s positions.and this “conversation” has been very beneficial if you discard the “getting personal” pieces. Many good points have been raised all around that we will certainly keep in mind as we move forward. This includes looking at ways to allow our stuff to integrate with other tools.

  • http://community.hdri.net/blogs/chads_blog cmyers

    w/r/t Google Code, Code Plex, etc.

    Gosh, I’m really nervous about the current slapping match between Microsoft and Google. Does any one else worry that one of them might decide to pick up their marbles and go home and somehow manage to screw all the developers in the process?

    Microsoft has been Evil(tm) for some time now, and now that Google has gone IPO, they must be Evil(tm) because they have shareholders to answer too (just like MSFT).

    Neither are hosting code out of the kindness of their hearts. Of the two, MSFT has, perhaps, better motivations (promoting .NET). What are Google’s motivations? Getting ad revenue? Adding good will in the Dev community to get people to use more Google stuff perhaps? I don’t know, just speculating.

    Doesn’t anyone worry about all that I.P. these two giants have in the palms of their hands right now?

  • http://community.hdri.net/blogs/chads_blog cmyers

    Follow-up: Scott harps on this a lot and he’s absolutely right (pardon me if I’m not getting your thoughts just right Scott :) ) — Design for the domain, address the business problems and let the software evolve to meet those problems and add in frameworks when necessary.

    Big frameworks (like CAB, EntLib) seem like a Have-Solution-Need-Problem approach to design and that’s another reason why I always had a negative gut reaction to them, even if I couldn’t explain it until now.

  • http://community.hdri.net/blogs/chads_blog cmyers

    Jeremy:

    w/r/t frameworks, you touched on the real answer that hasn’t (at least not that I’ve yet seen) been fully discussed.

    The CAB vs. NHibernate argument was a big popcorn-kernel-in-my-teeth for me. Somehow, even though NHibernate was a Big Framework(tm), it didn’t cause me concern like CAB, EntLib, and other Big Frameworks(tm) like it do. Why??

    Here’s the answer (which you mentioned, but missed an opportunity to really nail the point): NHibernate, Log4net, StructureMap, etc easily integrate into existing code and do not, for the most part, change the design overall.

    Frameworks like CAB, EntLib, and most of the P&P stuff are very heavy-handed and force you to adopt their whole way of thinking. While that’s not necessarily bad, and can still result in Good Solutions as Sam and others’ experiences have revealed, I think ultimately the .NET community (indeed, most development communities) needs to focus on mix-in style frameworks rather than heavy-handed burn-the-base-class frameworks.

    There are two schools of thought here, it seems: Those who are TDD and realize IMMEDIATELY the value of a mix-in framework vs. a heavy-handed framework, and the more ‘classical’ (non-pejorative) bottom-up framework/foundation design.

    This is why the Entity Framework guys didn’t ‘Get It’ at first because they were thinking classically and couldn’t understand the mix-in model (or did, but couldn’t do that for some other reason).

    Many of us have worked extensively on both sides of the tracks and so far, my personal experience has been that the mix-in approach (even if TDD isn’t practiced) yields better results and allows for more flexibility.

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    I thought about that. How have you liked it so far? Easy to make releases & edit websites?

  • http://www.bellware.net ScottBellware

    Maybe Google Code might be a good candidate for an SVN host for StructureMap…