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:
- If you understand the underlying patterns, you are much better equipped to bypass the CAB
- 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:
- Do you use source control? -- Oh lord, I hope so. That's right up there with wearing sunscreen out to the beach
- Can you make a build in one step? -- 2 for 2. Absolutely necessary for frictionless work.
- 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
- Do you have a bug database? -- Yes, but you *can* do it in a very lightweight manner
- Do you fix bugs before writing new code? -- Amen. See the above on "finish what you started"
- 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
- 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.
- 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?
- 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.
- 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.
- Do new candidates write code during their interview? -- That's an awfully fast way to separate wheat from chaff
- 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.