Last I remember there were some 80,000+ open source projects. There’s a whole host of different solutions out there that solve the same problems. The MVC framework space is overflowing with Struts, Webworks, Velocity, JSF, and a host of others. The ORM frameworks include iBatis, Hibernate, JDO, and a bunch of others.

There’s a few rules of thumb I tend to use for whether it’s worth adopting something:

• It keeps turning up on popular java sites like The ServerSide (TSS).
• Multiple books have been written on it. One book is never enough, because there’s plenty of one off books on ideas that never really took off. SQLJ comes to mind off the top of my head.
• It solves a specific limited problem domain and relies on things like simple POJOs for its implementation.

At this point the framework is probably worth a look. Right now I’m looking into the Spring framework as a good way to make our applications more testable. After I get through O’Reilly’s Spring: A Developer’s Notebook I’ll have a better idea whether it’s worth adopting.

So far after using JBoss 4.0 for 6 months or so we’ve seen pretty good hot deploy response. Under 3 it was flakey and so you usually just restarted the server. Today we ran into a weird problem with a war file where a fix that had been added wasn’t getting picked up. After a couple of tries at redeploying it became time to resort to the usual tricks.

• Drop into the server/default/tmp and server/default/work directories and delete everything related to that war.
• Reboot the server itself
• Redeploy the war with a new name

So far none of these have worked so Monday we’ll have to get really creative. I just love finishing a week with an unsolved configuration issue. Really starts off the weekend on the right foot.

I gave the second of two lunch and learns today on our company coding standard. About a year ago when I first came on board, I went ahead and ordered twenty copies ofThe Elements of Java Style and handed them out to the developers. Looking back over projects after a year it was obvious that we weren’t all on the same page with our coding conventions. I’ve seen classes named Person_fb and lots of really short variable names like ln, p, and cur. And some of the developers liked curly braces on new lines even though the style guide declared they started on the same line as the declaration of the block.

public void doSomething() 
{
  // do something
}

instead of:

public void doSomething() {
  //do something
}

Constant names often looked like mail_server or pdfDir.

So as an attempt to pull everyone back onto the same page I setup a lunch and learn on the top 10 coding conventions from the book.

You can find the powerpoint slides here: (I’ll probably do the next one in KeyNote.)

powerpoint stack

After having worked in professional services organizations for about 5 years it feels a bit surreal, maybe a whole lot surreal to be evaluating RFP responses. I’ve been sucked into the evaluation process now for a couple of RFPs and I’ve come away just amazed of some of the assumptions that go into the process.

First, when you send out a blind RFP to 6 or 7 vendors you tend to get about a 50% return rate. When a vendor sends in a response last minute, or a little late this means the vendor probably isn’t really interested in bidding and this shows they’ll probably be late and sloppy in their work. This is the assumption. The reality is a little more complicated.

Having worked in smaller and boutique consulting shops you simply don’t have the manpower to respond to every blind RFP you get. In fact if it’s a blind RFP even if it’s right up your alley a lot of times you skip it, because a blind RFP usually means you don’t have a shot in hell, they just need to satisfy the requirement for at least three ‘competitive’ bids. So if you don’t have an in with the company and know someone on the inside you usually pass on it.

Assume though business is slow and you need to fill up the pipeline with opportunities so you decide it’s worth responding. You have to work this in around your billable work with the current paying clients. That means on the day before the RFP is due you meet up with a couple comrades and order some Chili’s takeout and spend 4-5 hours trying to guess at what the clients want from their vague RFP. You also try to figure how you can actually deliver given that it always seems to be a fixed bid and sometimes often they have you “guess the budget”. Finally at 12:30am you finalize the response and double check the pricing and then send it off for the sales guy to review in the morning. You send it off and bang your head on the table a few hours after they send it off client because you referred to working together with “BigName Client”, but you sent it off to “Company X” and forgot to search and replace everything. Hopefully the client will overlook that.

Second, a lot of consulting RFPs are for consulting services. So it’s important to rate them primarily on the quality of their RFP response. The resumes they attach on the end are really secondary. Of course people aren’t important, proposals are.

I’ve sat in meetings dumbfounded how we’ve eliminated often the strongest responders who have staff who are thought leaders in their field, regularly present at conference, and write well respected books. Usually this is because they didn’t spend enough time responding to the exact format of the RFP, or they suggested a different approach such as a formal mentoring plan or have more experience with Scrum versus RUP.

Third, when you bring in the companies to give a presentation don’t worry about interviewing any of their staff in depth, because again it’s about the process not the people.

Instead you should spend most of the time letting the 4 sales people they brought with them explain how they add value and how they have a brilliant patented methodology. Of course only one of these people has sales in their title, the others are the Account Executive, the Delivery Manager, and the VP of Professional Services.

Came across this little tool, Ashcroft courtesy of ThoughtWorks, today to try to really enforce TDD. Helps to enforce some good practices, but I’m not sure I could live with the “dictatorial” approach. Probably a sign of my own weakness. I do love the concept of making sure the entire suite of unit tests only take a few seconds to execute.