David Siegel of Creating Killer Web Sites would be proud. Rands has composed an entrance tunnel leading to the home page for his new book Managing Humans. Rands terms it a ‘SLIDESHOW’ but there’s no hiding an entrance tunnel. I shed a tear remembering the last time I visited a site through an entrance tunnel back in the late 90s.

I’ve already ordered the book.

Brows furrow, fists clench, throats tighten. Our domain logic is lost in legacy systems. I look back at any significant project that interfaces with our mainframe and see lost opportunities. We could have real domain objects interacting with relevant behaviors, but instead we dutifully write dozens of data objects full of getter/setters and little else. We pass off all the business logic and processing to the mainframe.

Even time is a concept we’re asked to check with on the mainframe. Since there’s some strange issues in some of the legacy code and the entire design paradigm was to run everything in a batch mode we can’t even rely on time. Real world time is useless. Setting your time by Network Time Protocol (NTP) is dangerous. Time is just a setting to control when your jobs run.

Mike Witters has seen the anemic domain model as well:

There was almost no logic involved outside of validating UI input. Almost everything from a logic perspective was encapsulated into the legacy systems or database queries: pricing, searches, margin calculations, etc.

We’re still working on it, but if most of your domains are left to your legacy systems you really don’t see the benefits of OO. The promise of a healthy domain driven design remains. Future web mainframe integration projects discussions will center around these ideas.

try {
  AddressEntityBean addressEntityBean = addressHome.findByCityAndStreet(city, street);
  addressEntityBean.remove()
} 
catch (Exception e) {
  //this guy is already gone
}

Brian Marrick explains the difficulties in trying to convince developers of TDD goodness. His first approach is to dive into some of their existing code:

This works maybe a quarter of the time. When it does, it’s the best: it shows the watchers exactly what they’ll be doing. The usual reason it fails is that the code wasn’t written test-first, so it’s hard to do anything without instantiating eighteen gazillion objects. A team has to learn to deal with that eventually, but dealing with it as the very first thing really drains the appeal out of an introduction.

Next he tries just starting over showing how the application could have been developed test-first:

I don’t know about you, but when I’m starting to build a new app, I often spend a lot of time thrashing around, trying to find a good working division of responsibilities into classes. Eventually things settle down to the point where adding new features isn’t an Adventure in Reconceptualizing, but instead becomes what it should be: fairly straightforward. I’ve gotten more-or-less used to the turmoil (though I still wish I were smarter or more experienced). The problem is that it makes me look like a complete idiot to watchers. Worse: they may not blame me. They may blame the technique, decide it’s stupid.

And the other issue is:

They look at how much we’ve accomplished in an hour or two, extrapolate that to the size of the existing code base, realize they have a long slog ahead of them, and turn off emotionally because they were hoping for some quick ladder out of a hole years in the digging.

My own approaches have yielded similar results. Last time I ran a one day training seminar on TDD I used Bob Martin’s bowling kata as the central TDD example and some smaller lab examples. For a few people this was compelling, but for many it was, “How does this apply to me day to day writing DAOs, JSF, and portlets?”

I backed that up on my team with a simple requirement. You will write tests and the coverage on your project should be at least 70-80%. I didn’t enforce test-first, but I strongly encouraged it. Over time this worked on my team. Across the other two development groups it was only partially successful.

My current approach is to write up a seminar with labs on doing TDD with JSF which is the point I hear most cited by my staff as the difficult part of doing TDD. Many of them are quickly lured into constant checking that their JSF backing beans do something in a browser. Unfortunately doing TDD with JSF is a bit painful so I haven’t completed that exercise yet.

For many developers dealing with frameworks not designed around being testable just adds too much of a burden to adopting the TDD practice. The rule now is newer frameworks tend to have testing backed because open source developers are generally fans of TDD. Ruby on Rails is a prime example and Wicket and Tapestry in java even has a built in test packages.

Time and commitment have worked well in my shop. Giving people the time to get comfortable and understand the benefits of TDD while gently prodding them all along the way has worked even if it took more than a year to accomplish. As more frameworks, libraries, and applications are built test-first by default–developers will start practicing TDD by default.

Scrum Master Jar Jar: “Meesah wanna know, What did yousa do yesterday?”

– Software Maestro

This parody isn’t too far from a really badly run standup. I’m sure some of these happen out there, and I’m sure some developers despise meetings so much they’d hate even a well run standup.