My clearest memory of how powerful transparency can be was in a discussion years ago with a Fortune 500 E-commerce VP. We’d successfully done a few million dollars of e-commerce work for them over the period of about a year and he was asking if we could develop about 15 sub-sites localized for places like Iceland or the Philippines on the cheap. They were hoping to get each of the sites done for $10k to $15k. My answer was simple:

While we’d love the work, we just aren’t setup for doing these small sites and you’d be better off going with someone else for developing small market sites.

At this point I was worried. You really don’t want to say no to a customer, in this case probably our second largest customer. The VP answered succinctly:

Thanks, Ed, we really appreciate your honesty.

They did end up doing the sites through someone else, but they kept our relationship intact and we ended up doing even more work for them that played to our strengths.

I replay this memory when I get hammered for pushing transparency over leaving someone out of the loop or only presenting the positive side to an approach.

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.)