The value of having continuous integration of your code is everyone knows when someone broke the build. The two most common errors are forgetting to check in all the changed code from someone’s desktop or forgetting to run the whole test suite before checking in.

There’s a tiny bit of guilt associated with breaking the build under normal conditions. Then there’s the times that make you scratch your head.

Like, the developer who checked in a single java class with the compelling CVS comment:

This doesn’t compile.

Then there was the retort long ago from another developer who had broken the build by forgetting to check in a class. It turned out the class he hadn’t bothered to check in that was being referenced in other classes didn’t actually compile. He sent a cryptic email explaining this:

I can check in the class if having an unused non-compilable class in CVS is a problem for you guys.

Only problem was the ‘unused’ class had several references to it in the code. Strange understanding of unused.

They do make for good war stories.

Tomorrow we’ll demonstrate Fitnesse tests for a complete 30 days of work to the whole team. We’ve piloted Fitnesse tests before for portions of a Sprint’s code, but never for an entire Sprint’s worth of work.

Our experience so far:

• Some of the team is still having trouble understanding what Fitnesse is for. Responses have ranged from “OK, I think I get it,” to “We didn’t sign up for this.”
• The developers have understood it best, but we’re championing automated acceptance tests.
• QA has been easier to involve with writing tests, and they have helped add extra scenarios.
• Business analysts are still taking a wait and see approach. They’re writing use cases for the first time. Fitnesse with its’ wiki type approach is still an additional input they may not be quite ready for.

I’m hopeful we’ll turn some heads tomorrow at the review.

Well we’re seeing a lot more MySQL customers these days.

— from a manager at a DBA outsourcing company

Purely anecdotal evidence, but I assume as databases like MySQL have proved themselves capable of doing a comparable job to Oracle, DB2 or SQL Server the cost issue has begun to make a difference. And if you’re a new business then a commercial database isn’t compelling. When more of the enterprise software vendors start supporting products with an option beyond Oracle, SQL Server, and DB2 adoption will increase. That took a while for Linux, but eventually everyone started to support at least RedHat for their enterprise software installs.

Could also be that companies hacking together a site in PHP who don’t know much about databases have to go looking for help as soon as they get large numbers of users.

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.