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.

I know I’m in trouble when the developers all start explaining how they skipped out of a two day training session after the lunch break on the first day. Once again they volunteered to attend a training session that was a lot more “death by powerpoint” then a true training session.

I often refer to these kind of situations as random training. It’s such a common anti-pattern that when you see these developers in vendor classes they explain in their introduction to the class that they’re not sure why they’re here since they’ve coded Oracle Forms all their life and they’ve never coded in Java before. What’s happened is their manager probably had one of the following thoughts:

• There’s a training plan in my employee’s goals for this year so this will let me check off that box.
• We had training credits we need to burn.
• I heard Oracle is moving to Java and so our DBAs need to get up to speed.
• We have a pilot java project starting in 6 months, so I’ll send Sue to get her ready now.
• We brought in a custom course on site and we need to pack it with any IT employees to fill up the class and really get our money’s worth.
• After a week of classroom training our junior developers will be ready to leap into cutting edge development on our new technology.
• I know Sue wanted to go to an industry conference, but that costs travel money and this class was local and on a big discount.

My personal philosophy is management should try to provide at least a week of classroom training or a week at a high end conference per year. That and buy stacks of technical books for anyone willing to train up on a new area.

General details about JUnit 4 are starting to leak out and you can find more of the discussion at Cedric Beust’s blog. He’s one of the people behind TestNG which is an alternative java based unit testing framework that built on perceived problems in JUnit including things like the brittleness of having to build suites and adds supports for annotations.

While I applaud the TestNG folks and others for enhancing unit testing in Java, I never considered for long switching to TestNG despite looking into it a few months back. There is the notion of momentum and JUnit has tremendous momentum including books, heavy tool support, and mindshare. TestNG has support for Eclipse and being an IntelliJ user this just doesn’t do me a lot of good. I also have to learn a new way to doing thinks, new ant tasks, and there’s no good books to point to. So that means every developer I expose this to I’ll have to train up or expect them to spend time digesting the tool. There cost of switching is just too great. And the cost of waiting to see which wins out in the open source market place is just a lot easier.

I’m looking at pretty much the same situation with Subversion versus CVS, but there I expect to be able to migrate to Subversion within 12 months. Subversion from what little research I’ve done just builds on CVS. So when the tool support comes in I’ll take the time to spin everyone up on Subversion. And if I’m wrong CVS is still really workable in an environment where are largest project has 6 developers on it.