Mock frameworks can generate an ‘aha’ moment if you introduce them at the right moment. The evolution looks like this:

1. Introduce unit testing as a concept.
2. Walk through the basics of an xUnit framework.
3. Introduce test driven development.
4. Introduce fake objects or hand rolled stubs to substitute for things like DAOs.
5. Use specialized mock object libraries like Shale mock JSF framework to build fake FacesContexts.
6. Spring EasyMock or JMock on them to handle some nasty edge cases.

We choose EasyMock. Introducing it right up front would have been cognitive overload. Getting TDD installed is really more a journey than a simple prescriptive plan. TDD is about changing a core developer behavior in how they write code. So I saved the mock framework explanation for that moment where it elegantly solved the problem at hand.

James Ward from Adobe came out to give a presentation on Adobe Flex. Some of the demos were really impressive, especially the one with a simulated book that you could turn over and fold pages on. He covered Apollo as well. He’s touring around as a general evangelist.

The SACJUG peppered him pretty well with questions. Any new tool/framework especially one that isn’t fully open source will always raise eyebrows with developers. He got a few questions about whether it could run on 64 bit Linux versions. Turns out it can, but there are some caveats about running it in 32 bit emulation.

Flex is a front-end framework utilizing Flash and ActionScript (aka Javascript 2). You can hook it up to back end data services as well. I don’t think we’ll probably be using it in our shop anytime soon, but it never hurts to keep up with these things. And next time my web developer brother asks me working with Flex I’ll know what he’s talking about.

I’m the wiki champion at work. It didn’t start out that way. We brought Confluence in house at the urging a motivated tech lead. The champion set up the wiki and ran training sessions for a while. Soon after they moved on to another position and I inherited the wiki champion belt:

A passionate, enthusiastic champion is essential to the success of wiki because s/he will be able to generate interest, give the appropriate amount of training for each person at the right time, monitor growth of the tool and fix problems that could derail adoption.

— wikipatterns.com

Turns out I probably am responsible for 25-33% of the current activity on our wiki. I dump everything there from velocity logs on projects to tips on troubleshooting build problems. I’m still trying to gently drive adoption since I want to avoid the “All wiki all the time” pattern.

If you hear people saying, “Oh no. Not another wiki!” you might be moving too fast. Pushing to use the wiki for everything too quickly can hinder its adoption for several reasons. People might not feel comfortable with the wiki yet – it’s a paradigm shift for most people to imagine using a site that doesn’t require approval to post content, and where others can edit or even delete what they’ve written.

— wikipatterns.com

I’m not sure anyone else will find this of much use, but the following is a list of tools, frameworks and libraries we use currently:

Java Frameworks

• JSF 1.0
• MyFaces
• AJAX Anywhere
• Spring
• Hibernate
• iBATIS
• JUnit
• EasyMock
• Log4J
• JODA Time
• Struts (Though just for one 3rd party app and some older applications)

Tools

• RAD 6.0 (We’re a Websphere shop these days)
• IntelliJ IDEA ( Was the editor of choice before Websphere, still used occasionally)
• Hudson (our current continuous build tool)
• Confluence
• HSQLDB (for in memory testing)
• Crucible
• Clover
• Fisheye
• CVS
• Tomcat
• WAS 6.0
• Websphere Portal 5.1
• Websphere Process Server
• Ant
• Maven 2 (Used for one or two projects at this point)
• Checkstyle
• PMD
• FindBugs
• Fitnesse

Practices

• Scrum (30 day Sprints)
• Test Driven Development (We’re still working on this, most unit tests are still written after the code.)
• Lightweight Code Reviews
• Domain Driven Design (Really just getting started here.)
• Continuous Integration
• AOP (But just a little bit with Spring 2.0)
• Use Cases
• Automated Acceptance Tests (Again, just getting started here.)

It’s really easy to mistake “busyness” for productivity. The folks always rushing around, having meetings and complaining about how busy they are certainly LOOK like they’re doing a lot. But the reality is that effort and output are not always related. Productivity is about getting loads done — how you spend your time should be up to you.

Coming in at 8:00 reading email, attending a few meetings while checking your CrackBerry a lot, going to lunch, then spending most of the afternoon writing documentation on software that’s already been completed and tested is very low productivity. Sure you’ve spent 8 hours working, but there’s very little to show for it except say for some very low value documentation that no one else is likely to ever read.

This happens all the time in large consulting projects. After the firm lands the work they go out and hire any contractors they can find on short notice. They dump them out on the client site and start billing 8 hours a day. Maybe the project actually does get done eventually, but generally it’s a few of the developers that do the bulk of the work. Many of the other junior contractors may actually be adding reverse productivity by injecting bugs as they produce line after line of cut and paste code. From a pure clock watching activity the lowest skilled developer on the project has probably put in more time than the most productive person.

The real problem is time is an easy metric to track, while productivity on a software project is difficult. Tracking hours billed or percentage done is easy. Tracking software quality or features completed requires more effort and certainly more technical knowledge. There’s plenty of false technical metrics that have been used from lines of code to the number of function points completed. Both of these measure how much typing you’ve done, but the best systems have as little code as possible necessary to implement the features that are actually used.

The best metric I can see with productivity is how many production quality features are getting done and how quickly. You can measure the ROI on something you can deploy at the end of any iteration, you can’t measure any ROI on the fact that you’re 80% done with the software design.