Larry Dignan of ZDNet blogged about the sad state of corporate IT. He mentioned a speech from Gartner analyst, Steve Prentice:

“This industry is in danger of becoming one of failure. We’ve come to accept mediocrity as the norm. It’s not a lack of technology or skills. The problem comes down to a lack of vision.”

His key reasons included:

• Consolidation in the hardware and software markets is slowing innovation and managers are just waiting around for upgrades.
• Technology managers aren’t innovating, their waiting for their Enterprise software upgrades and CEOs want innovation.
• India is leading the way on innovation now.
• Technology is getting consumerized, but most companies are trying put up higher walls to block out IM clients, wikis, Google apps, etc.
• Software as a service is going to dominate, but corporations try to just keep buying enterprise solutions that have to be installed, customized, and maintained in-house.
• Green IT matters.
• CIOs that focus on the status quo and just keeping existing systems up and running will be replaced.
• Legacy systems just keep growing. This piles on complexity with difficult to maintain applications.

It’s a long list and despite the need to take anything from Gartner with a large grain of salt it fits with my past and present experiences. The basic message is corporate IT is largely content to tread water. The pattern is:

• Keep your current systems up and running.
• Continue to build out your legacy mainframe or client server applications because it’s easier than thinking about how to wall them off and gradually replace them with newer, more maintainable systems.
• You put your trust in big Enterprise vendors and then wait years between updates paying expensive maintenance fees every year. And when you buy new servers you can double your costs overnight with per core and per processor licensing schemes.
• Try to keep your users from using any software outside the firewall, slamming them with the security club until they submit. Smaller, newer companies are able to get up and running at a small fraction of the cost. They don’t let security trump all efficiency arguments.

The good news is there’s still plenty of time to reverse the trend and the end users may well force the issue much as they did with PCs and web.

You fight enough battles to remove impediments and eventually you stop beating your head on the wall. A lot of impediments can be removed with some attention and pestering, but others are above your grade to change. Often after a few attempts you learn to accept sub-optimization.

Lately I’ve been given a few lessons in returning to try lost battles again. In quite a few cases finding a good collocation space for a team is difficult. Spreading a team out across floors or building takes a nasty toll on communication and the inspect and adapt cycle. Still furniture police intimidate you into just moving on to look at different battles.

Maybe my guerilla fight for team collocation is earning dividends. In the past several months two other managers have fought and won battles to move teams into collocated areas. While I had dropped the fight for both of the teams, others with a fresh perspective simply spoke up and got some cubicles moved. And in both cases it made a big difference for the teams.

Aspects of Agile are beginning to cut furrows into our corporate process.

Lasse is writing a Manning book on practical TDD and acceptance testing for java developers.

I’m so excited I purchased the early access addition, signed up for the author forums, and started skimming the PDF of the first four chapters tonight. This is exactly the text my team and so many other java development teams have needed. Up until now I had a big todo on my Someday/Maybe list entitled:

• Write a developer notebook style on unit testing java web apps (especially TDD with JSF)

Now I’ll actually see the concept in print.

Other Texts

As an early adopter it’s fairly easy to get caught up in TDD and forget how painful it can be to implement or understand for developers in the early majority. In the past I’ve looked at several texts to help transition my team:

Test Driven Development – Beck is great getting across the concept, but when you have to move past implementing a Money class and deal with things like Struts, JSF, or iBATIS and Hibernate the gulf can be hard to cross.

Pragmatic Unit Testing – A good overview text including the idea of fakes and mocking. Jumping to effectively testing a J2EE app is still a wide ravine.

JUnit in Action – Again another good introduction, but some of the solutions to deal with J2EE troubles is to utilize Cactus to do in-container testing. Your testing times really start stacking up.

JUnit Cookbook – A great sample of recipes that finally addresses some of the nastier cases like how you test JSP output. After looking all the ways to deal with testing JSPs I just felt dirty. And because it’s from 2004 it largely ignored the difficult to test world of JSF.

Agile Software Development, Principles, Patterns, and Practices – I love some of the TDD examples in here and the bowling game is a now a classic. Still the gap exists in how to apply this in J2EE land.

Acceptance Testing

Lasse is tackling unit testing the J2EE stack along with acceptance TDD. Introducing Fitnesse has been a big focus for the last year and we’re starting to really utilize it on projects. Still it suffers some in the documentation area and even the one book out focuses on FIT and ignores many of the gotchas that come up on Fitnesse.

While I think TDD has started to move closer to the mainstream, acceptance testing is still fairly leading edge from what I can see. I think quite a few java developers have heard of FIT or Fitnesse, but very few have even tried it out.

Conclusions

This just really bandages up a nasty pain I’ve had for too long around TDD, acceptance testing and J2EE. Two years ago I would have ordered twenty copies, put together some labs, and setup a reading group. It may have cut months of our adoption curb. Since we were more on the leading edge I got to figure out a lot of this as we went along from using the Shale mocking library to driving adoption by making setup easier with ObjectMother patterns.

Just skimming the first four chapters, knowing the quality of Lasse’s postings over the years, and realizing there is still much to learn I expect great things of this book. I’m sure I’ll be ordering a dozen copies come September.

Many thanks to Lasse for spending many future hours hammering out this tome.

About a year ago in a session at SD Forum 2006 Dave Astels related a story on how one manager approached mandating TDD on a team:

• Move the whole team out to a new collocated team room.
• Outfit the team with brand new equipment.
• Brought in Dave to mentor/coach the team on TDD by doing a lot of pairing.
• Mandated that all code was unit tested.
• Mandated user stories and acceptance tests written into Fitnesse.

Impressive story, and probably the sort of boss I’d love to work under. After two years we’ve finally realized much of the goals I set out to accomplish:

All of my developers are writing tests, some TDD and some just in close proximity to writing the code, but average code coverage is 75-80% and defects are down more than 10x from just two years ago.

We’ve put Fitnesse in place and are writing acceptance tests for the first time.

Two of my developers are even pair programming by choice.

It took two years, which feels like a long time to me. Could a shock treatment have worked better? I think given our environment where most of the developers were brand new or relatively new to OO or Java adding in all of the TDD approach would have largely backfired. Maybe we could have done it in a single year, but I’m still really proud of my team.

There’s not much better than knowing that you’ve been able to really grow your team out into a high quality group of software developers conversant in most of the XP practices and constantly willing to learn and improve.

Being right later is a symptom of a nasty disease. You knew the problem was coming, you tried to convince people, possibly even earnestly, but they choose the risky path anyway.

Self reflection reveals:

1. You’re not communicating effectively.
2. You’re not trusted.

Painful, yes, but if all the evidence points one way you have to face it. Many technologists focus on the logic, the details of the arguments, and assume that the overwhelming evidence will win out. Often an emotional appeal will crush an overly rational argument. Since code or mathematics don’t behave this way it can defy comprehension. Heck, many developers ended up coding because it’s such a nice logical world.

The second possibility is that they’re not hearing your arguments because they don’t trust you. That lack of trust can be simple hierarchical status. I’m higher up in the organization therefore anyone lower in the pyramid probably can be safely ignored. It could also be that they’ve tagged you based on some past mistake. Doesn’t matter that you’ve had 10 big successes since then, they’ve mentally checked out of your arguments, because you screwed up on big Project A 5 years ago.

Communication can be worked on and built up. Trust unfortunately tends to be a long term fix. In the mean time you can find yourself wanting to say “I told you so!” constantly, but it’s just counterproductive. If you’ve lost that trust in a corporate setting it’s often just better to be successful elsewhere.