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.

Learned some things today to get something running with Clover. First off I learned that Clover uses it’s own embedded version of ant unless you specify otherwise. IntelliJ does a similiar thing, so you just have to tell it where yours is so it can use your version of ant.

<schedule interval=”60”>
  <ant anthome=”C:\apache-ant-1.6.5” buildfile=”cc-build.xml” target=”build”/>
</schedule>

This took me a little while to catch until I noticed the console was reporting running 1.6.2 and I only had 1.6.5 on the machine.

I had all sorts of problems getting the Clover html reports to run until I added fork=”yes” to the

Michael Feathers defined today his idea of a unit test:

A test is not a unit test if:

• It talks to the database
• It communicates across the network
• It touches the file system
• It can’t run at the same time as any of your other unit tests
• You have to do special things to your environment (such as editing config files) to run it.

Currently about 90% of the time I manage to meet these requirements with my unit tests. Still occasionally I write a functional test or an integration test. A lot of times I keep these separate and let Cruisecontrol run them. My plan is that all the true unit tests run in about .5 seconds.

One of my teams is finishing up a small project now with about 20 unit tests, but they all invoke only POJOs and depend on an in-memory implementation of the DAOs instead of starting up a hibernate session and connecting to the real database. While the project could use more tests, the tests get run fairly often because they are so fast.

Another of our projects has 700+ ‘unit tests’. They break pretty most of Michael’s rules. The connect to real databases and communicate across the network in test after test. The nasty part is they take 30-40 minutes to run. They never get run except by Cruisecontrol, and because they are largely large functional tests in reality they’re hard to debug and about 17 right now are failing and no one has had the heart to fix them in weeks. This of course says a lot about the project in general, but the lack of focus on true unit tests has always really hurt.

My sense is out in the real world, a lot of people who bother to write unit tests mostly write functional tests that often connect to a real database. No wonder they don’t see much value in them.