Caught the new announcement on TSS about IBM’s newest line of WebSphere products. The comments at least at this point are pretty scary. They’re about 75% negative, mostly that RAD is a junk IDE, Websphere has a horrible deploy that takes forever, and all their products dump out useless error messages. The few positive posts are mostly from IBM employees. (2 of the 3 actual positive comments are from IBM staffers as of 9/17.)

I’ve been avoiding dealing with our WebSphere tools since we made a purchase a few months back. My plan was if we needed to we’d open up RAD for doing some portal integration or BPEL work, but pretty much stick with IDEA otherwise. I probably naively assumed that we could deploy to WebSphere as easily as we hot deploy to JBoss 4. Maybe this is all FUD, but I fear not.

Listening to an Agile Tool Kit podcast interview with Bob Martin from the Agile 2005 conference yesterday he mentioned that you really only needed three factors for an agile project:

• Short cycles
• Unit Testing/Acceptance Testing
• Collocation

Short cycles are easy most places. You can generally do them even if the process is very BDUF oriented because you can simply start coding earlier and demo at the end of say 30 days. I’ve found this one fairly easy to institute.

Unit testing would seem easy, but I’ve found this actually a lot more difficult to implement in practice. Most web developers just don’t see what writing tests is going to do for them. TDD is a foreign concept. Then many of the web apps that get written don’t have that large a scope so they don’t tend to have a lot of defects if the developer is pretty diligent doing manual unit testing or the GuruTestsCode pattern. And then most web apps make use of two traditionally hard to unit test items, databases and GUIs.

Collocation seems easy, but mature companies are incredibly anal about turf. They don’t want to give up a conference room for months. Oh, the project might be critical to the company, but we couldn’t possibly give up space for it, where would anyone hold a weekly staff meeting complete with doughnuts.

I just learned today that our largest project has been canceled after 3 years. I’m still in a bit of shock that a decision was finally made. The project had every sign of going wrong over the last 3 years.

• It was a huge rewrite of a legacy application into a web application.
• It was going to be done in 6 months.
• It was supposed to add totally new functionality.
• Perhaps one or two of the developers had ever built a really large application.
• After 6 months no one could agree on the requirements, but the developers started coding anyway.
• The scope of the project completely shifted 3 times.
• All of the business logic and backend code was being done by a single developer.
• It added an enterprise rules engine that was going to allow business analysts to write the rules without any help from the developers.
• The new rules engine was going to save the project.
• One of the business rules documents contained a matrix with over 2000 business rules.
• A customer was never defined.
• The system had to have zero defects to be released.
• There were over 10,000 manual test cases run by the QA staff.
• There were over 1500 defects.
• There were two levels of validation known as Level 1 or Level 2 edits with different functions.
• Every lead on the project recommended killing it as the project progressed.
• It had 700 tests, but 500+ of them were functional integration tests not unit tests.

I think you get the picture. Anyway I feel remarkably free having a clean slate in front of me.

With some of the silly facilities fights I end up in, I’m a little jealous seeing my twin brothers office digs at three40.com. I sometimes have trouble getting permission to hang up a corkboard.

Nice Brick Walls

Twin #1 at work.

Baby visitors.

Twin #2 at work.

Ever been on a project where everyone smiles and says, “Oh, you’re on the Chat Server 2010, isn’t Abe on that project.”

This is generally the sign that you’ve been assigned with one of the company bozos. These are the employees who are generally incompetent, don’t care, don’t play nice with others, etc. Line managers love to migrate them over to other teams or large difficult projects where perhaps they can blend in with the scenery.

I started to run into the bozos as I worked on larger million dollar plus consulting engagements. At first you just assume they’re a little behind the curve on the technology or need a little more care and feeding to motivate them. Then as your efforts largely fail, you realize another manager somewhere has taken the easy way out.

Essentially for many managers invoking disciplinary measures or actual firing someone is the worst possible part of the job. In many ways it is, but this is of course one of the tradeoffs of taking on a management position, you actually have to make some difficult calls.