I should be practicing my DevTeach talks on the train home tonight, but instead I’m going to write a self indulgent post about random software development thoughts.
I finally got a post onto the Carnival of Agilists. I’m somebody now.
On Collective Ownership
I happened to notice an interview in InfoQ.com with Jeff De Luca on Feature Driven Development. I read it with some curiosity because I don’t really know much about FDD. From the little I’ve read about it FDD doesn’t really sound all that Agile to me — which is not to make a judgement that it’s good or bad, just that it seems much more like RUP to me than XP. In particular, I want to disagree with Jeff De Luca’s stance on Collective Ownership in that interview:
Collective ownership is code for “no ownership”. It’s not a structure I believe in.
It doesn’t take a brain surgeon to understand his concerns with collective ownership, but I think it’s largely driven from that pessimistic view that says developers can’t be trusted without being directed by a Stalinist project manager. My experience with collective ownership has been much more positive than projects that strictly used individual ownership. Here’s why I think this is so:
- Individual ownership creates knowledge silos, one of the worst causes of inefficiency in my experience.
- Collective ownership allows for much more flexibility in project scheduling because team members can work in multiple areas of the code. That’s a huge advantage.
- Individual ownership of coding modules will generate more duplication of effort. I’ve seen this time and time again. Even worse is the fact that styles and approaches can diverge quite a bit from developer to developer. Collective ownership with a decent amount of communication can lead to far more consistency in coding than putting developers in silos ever can. De Luca says “If you practice class ownership you get much better consistency of implementation and interface.” I think that’s almost pure bunk.
- Wait Jeremy, you address these issues by doing regular code reviews! Yes, but that’s not entirely a pleasant way to work. Like it or not, code reviews are almost inevitably a nasty, unpleasant affair when code becomes too closely tied to a single person. On the other hand, the general tone of continuous code improvement is far more positive in a project team exercising Collective Ownership. When you’re criticizing my code, I’m going to get defensive. When it’s our code, it’s much easier to divorce ego from the discussion. Even better yet, we can have better discussions about the code because we’re both familiar with the code.
- Collective ownership better harnesses the talents of the team. Again, individual ownership is inevitably going to put your weakest developers on an island.
- Collective ownership puts more eyeballs on each area of the code. Again, you can do this with code reviews, but nothing beats having multiple people actually work on the same area of the code.
- De Luca makes an analogy comparing individual ownership to the design concept of encapsulation. Yes, I definitely want my code to be encapsulated, but I really don’t want specialized developers. At least within an application or service, I want my developers to be knowledgeable about the system as a whole. I think it’s vital to understand how any one piece of code fits into the larger structure. Teams that specialize their team members by layer or technology are not as good as a team of people that can swing from client to server and back again.
- Individual ownership is partially driven by a command and control model of team management. Somewhere a project manager wants a perfect Jira record of every developer task so he knows who to yell at.
- Vacation, sick days, turnover. Guess which model handles those things better?
- The biggest reason: it’s just more pleasant at work with collective ownership.
Allay De Luca’s concerns over no ownership by simply removing any untrustworthy developer, or at least spend some energy to modify their behavior. I’ve never seen collective ownership be a problem in terms of developer responsibility. I care very deeply about the quality of the entire codebase, and I don’t particularly want to work with anybody who feels any differently. Again, I’m an optimist in regards to the abilities and work habits of developers and that optimism colors my philosophy of development.
Overall it’s a good article, even if it’s sprinkled with a touch of FUD in regards to other methods.
The Importance of Iteration Kickoff Meetings
Iteration kickoffs are obviously important for project management and scheduling purposes, but these meetings are also a hidden opportunity for an Agile team to:
- Create a common vision of the development work
- It’s a de facto design session to work through possible design approaches along the way to creating useful estimates
- Spread knowledge about the system throughout the team
Make it Configurable by Xml — Not!
Like many impressionable young architect wannabe’s, I went through a phase of infatuation with metadriven code approaches to make code easier to change. It always starts with the idea that if you express logic in Xml or database tables the system will be easier to change. There’s even the nonsensical idea that you can “just” change the Xml file on the fly to make behavioral changes. My magnum opus was a workflow system that could be customized through 67 different metadata tables (at the time it was a huge improvement over the spaghetti code ASP & VB6 app’s we had otherwise). On my current project I’ve almost entirely ditched that philosophy in favor of little embedded API’s inside the code itself that declaratively configure the behavior of the system. I’ll give you a couple reasons:
- You can simply make rolling out new code less risky and scary. Spend the investment on a good continuous integration solution plus a battery of automated tests. Take away the fear of changing and deploying new code to production and the Xml advantage largely goes away. If you’re afraid to change your code it’s time to figure out how to eliminate that fear.
- Intellisense
- Putting some logic in Xml splits the logic between code and the metadata. Sometimes that’s okay, and other times that just makes the system harder to understand
- When you change the Xml mappings or configuration you still have to test your changes and redeploy. Assuming the code is easy to build and deploy, what’s the difference between changing code and Xml?
- Fewer moving pieces to deploy
- Code can be so much more expressive than Xml.
Oh, and the people out there swearing up and down that giving the business end users a screen to configure a business rules engine themselves will save the day? BS. Drawing workflow’s with pictures is coding – with every bit of the risk and danger that coding brings. Only now you’re making noncoders code in the production system. Think about that last sentence.
ALT.Net
I don’t think that David Laribee quite knew what he’d unleash by coining the phrase ALT.NET. All I can say is that I think it would be nice to be one of the cool new kids that likes the bands you won’t hear of for years today, but a lot of the things already classified as ALT.NET look suspiciously like Agile Java tools from 3-4 years ago, with a smattering of Ruby influence for good measure. Someday I’d like to see some beneficial trend or development technique start in .Net and then propagate to other environments. It’s ironic to me to even be remotely associated with the Pearl Jam and Soundgarden loving community within .Net because I was the only college freshman in the fall of ’92 that really wasn’t all that wild for alternative rock music.
The VB(.Net) Community
I swear, I’m not bashing the VB.Net community here, but I’m constantly amused by the sense of identity the VB.Net community has with their language. I’m technically a C# MVP, but ask me what type of developer I am and I doubt that I’d think to say C# in the first 4-5 sentences. You know the VB.Net guys would say “VB!” in a heartbeat.
Getting Geeky
I’m working in one of the big financial shops in Manhattan and riding the train each day to work with a horde of folks in banker’s suits. It’s a much different feel compared to an XP team in Austin.
In a fortunately abandoned post on Model View Presenter (I know Martin split the pattern, but I’m talking about the supertype) screens, I was working up a pair of bad analogies to help developers new to MVP understand how to assign responsibilities between the view and presenter. Start the groaning…
- Don’t splash outside the tub – I have a 3 year old son who loves his bathtime, but I have to watch that his exuberance doesn’t lead to water all over the bathroom floor. When you’re working with MVP, the point of the presenter is to implement screen logic and behavior without being encumbered with view mechanics for easier testing. Don’t allow presentation mechanics to leak into your nice dry presenter. As a rule of thumb, you want zero references to either System.Web.* or System.Windows.Forms in your presenter classes.
- The “View” is like the levels in Half Life where you have to hold your breathe to swim through a sizable lake or sprint through some sort of poisonous atmosphere. You’ve got to cross that zone to get to the end of the game, but you need to get through there as fast as possible. In other words, keep your view as thin as possible.
Star Wars (original trilogy thank you) can be worked into almost any situation. At the MVP summit in March I bumped into a gentleman that had taught a 3 month battery of VB6 and Sql Server 7 classes that I took in Houston in 2000 when I was trying to weasel out of engineering and into software development. I wanted so badly to tell him “when I left you I was but the learner, now I am the master!” Sam gave me hell about the VB part of that. Finally, I’m working with another Finetix/Sungard developer who’s new to the entire ALT.Net canon of tools and processes. Just to dunk him in the deep water as fast as possible, we did a pairing session last week working on a screen that in two hours involved:
- A supervising controller design — think about seeing this for the first time ever if all you’ve ever done is autonomous views with a designer
- TDD with NUnit & TestDriven.Net
- Bouncing around the code with ReSharper. He made my day yesterday when I saw him using “CTRL-N” while he was working by himself.
- RhinoMocks
- Writing FIT tests
- Doing a check in dance with CC.Net
- Going to Subversion’s edit-merge model instead of VSS’s default pessimistic locking
At the end of the session I wanted to do the Obi Wan line to Luke learning to be a Jedi — “you’ve taken your first step into a much larger world.”
YAGNI isn’t entirely applicable to everyday life. The other day I was moving boxes for my wife from the basement to the upstairs when we came across a big box of DreamWeaver manuals. I tried to call YAGNI on that box to no avail. My hardback collection of Robert Jordan and George R. R. Martin et al books however, have been semi-permanently YAGNI’ed until we can move to a bigger house next year.
Ayende, if you’re reading this, you’ve already earned some eye rolling from my wife when I told her about “this guy who uses an alias on his blog from the Old Tongue in the Wheel of Time.”
