Willing To Give Estimates

Developers have no love of estimates. They’ve been pinned in a corner by an estimate and beaten to a pulp. “But you said it would be done by Friday!”

I don’t have any problem with a developer being reluctant to give an estimate. I do have a problem with developers refusing to give estimates unless they have everything nailed down in a nice spec document and they’ve completed their design.

You can’t know everything when you give an estimate, hence the term. You base your estimate on breaking down the work you think will need to be done into small enough tasks and then build from there. You take into account risks and any historical information you have. Then you give an estimate.

The business has a right to expect this. In no way does this mean the estimate will play out exactly. If it does, likely it was an overestimate and the developer simply backed into it. Estimates will get adjusted by reality. As you get more information you can update estimates and give better future estimates. Scrum builds this into the process as you change your estimates every day. The important point is how many hours you have left on a task or whether you finished it, not whether the actual time you spent on a task lined up with your original estimate.

Rant done.

Testing Legacy EJB Code

I’ve battled the EJB beast and come back scarred and wounded. I’ve tried many approaches and found none to satisfying.

First, there was hope with MockEJB, I got it working for some simple cases, but I got bogged down with more complicated test setups and dealing with intercepting EntityBean test methods.

Next came the idea of just using EasyMock. That worked well for testing the service layer that depends on some stateless session bean facades. You can mock the session beans pretty effectively by adding a simple setter and injecting the mock. Unfortunately the stateless session beans had lots of JNDI calls within methods to get entity beans. Without wholesale refactoring it just wasn’t going to work.

Then, touched on JB Rainsberger’s idea of pulling out as much logic as possible out of the session beans and just delegating to that class for everything. Unfortunately the session beans already need some refactoring because they’re too big. They implement a Transaction Script style. They make a JNDI call to get a home interface to an entity bean. Then they invoke a method or two on the entity bean. They catch exceptions, rollback transactions, and throw a new wrapped exception. There’s not a lot of real logic anyway except maybe for a bit of exception handling. I can look up the enitity bean home interface and pass it off to the pure POJO class, but I’m still stuck with try catch block. It just isn’t very satifying.

There were a few other attempts, that came to nothing as well.

Large legacy EJBs suck for testing.

SOA Registry for Five Web Services

I actually see people putting the cart before the horse. They want to go out and buy a registry. I’ve actually talked to a really large company. “We just bought a registry, we spent a lot of money.” I said, “Great how many services are you gonna put in that registry?” “Well we have three or four. And my point with those folks is, “You could keep up with that in an email or a wiki page. Why do you need a registry for three or four services.”

A lot of vendors will talk about governance. You have to have governance, if you don’t have governance you can’t build out an SOA. My point is if you don’t have services you can’t build out an SOA. Let alone governance to actually maintain, monitor, and manage the five services that you actually have.

Bret Sutter

I actually chuckled out loud on my way home.

Javadoc Clutter

I once thought Javadoc was a great tool. I added an ant target for every project I built. Now it’s just clutter. I saw another example of the pain point of Javadoc again recently on an internal project that isn’t designed to ever be used as an API:

/*
* Returns Publisher when passed Id
*/
public Publisher getPublisherById(String id)

/*
* Returns Publisher when passed Id
*/
public Publisher getInstitutionById(String id)

Just drives me crazy the comments fall out of sync with the code as soon as someone performs a cut and paste. And the darn things can double the number of lines in a class, especially when you have a lot of short methods. (And you should have a lot of short methods.) Uggh.

ScrumMaster Removing Obstacles

I had a lingering issue resolving connection to an outside VPN and getting into a CVS repository for weeks. I’ve been on and off trying to get it resolved between typical management tasks. Today I mentioned it as an impediment in Scrum where I’ve volunteered to do some coding. By 1:30 in the afternoon the problem had been solved. Sign of a Scrum Master on the ball.