Craig Pardey

My ex-project and I had been together for ten months. We had our fair share ups and downs, particularly in the early days, but over the last few months we had settled into a nice routine. It wasn’t particularly exciting any more but at least it was predictable.

And then yesterday I was asked to lead a troubled project. It’s only six months old and already has quite a few warts, and it limped across the line into UAT last week. My first instinct was to cower in the corner in the fetal position but I resisted that temptation and quietly accepted the role.

Sometimes your code needs to call a static method in a 3rd party library and unit testing  suddenly becomes difficult, particularly when that static method requires context in order to work.

Enter the insulating class (also known as a Facade).

1. Create a new interface that declares a method with the same signature as the static method you want to delegate to
2. Create a new Facade class that implements the interface
3. Replace the calls to the static method with calls to your new Facade class

Let’s assume that the method you need to call looks like this

I had an annoying problem on Windows 7 x64 with Helios x64 where I had pinned Eclipse to the taskbar but would see two icons whenever Eclipse was running. I found that the following workaround works with the option “Always combine, hide labels” for taskbar buttons.

• You must specify a -vm argument in your “eclipse.ini” file (in your Eclipse directory).
• The -vm argument in your “eclipse.ini” must point to the bin directory of your JDK or JRE (and not to javaw.exe). For me the argument is “C:/Program Files/Java/jdk1.6.0_27/bin/” without quotes.
• Unpin Eclipse from the taskbar or delete the shortcut
• Run “eclipse.exe” from Windows Explorer and choose your workspace
• Pin Eclipse to the taskbar after the splash screen has loaded and the main window is shown

Hope this helps.

I attended a talk at the Toronto Agile Tour on Deliberate Practice that focused on TDD Games and other programming challenges like Kata.  Among the challenges were things like solving a problem without using the ‘if’ keyword, or without using primitives.

Solving simple problems using these challenges makes us better programmers because they force us to come up with multiple, creative solutions to the same problem.

Here’s my solution for how to divide without using the division operator ("/") in Java. The method should take a numerator and a denominator and return the largest integer multiplier. For example 10/3 = 3, which would be called as int result = divide(10, 3)

“I’ve had a talk with the Product Owner, and he’s decided to let you guys have an extra week to finish the work for this Sprint”, my Project Manager said on Friday afternoon.

The horror! The horror!

My team and I did not manage to complete all the work that we’d committed to in the Sprint.  In the interests of open communication, I informed my project manager that there would be a few carry-over items.  The next thing I knew I was being told that we would get a Bonus Week in our two-week Sprint so that we could complete the functionality.

It can be difficult to be Agile when working with 3rd party software framework.  The vendor product may dictate many aspects of the software architecture thwarting your attempts at automated testing and continuous build.

However there are steps you can take to make Agile easier.  I’ll discuss a few of the options that have worked for me on my current project.

• Insulate yourself from static methods.
• Introduce wrappers (Facades) to vendor classes.
• Introduce Spring, with different contexts for testing vs production, to allow easy substitution of vendor classes.
• Make use of mock objects for testing your code in isolation.
• If possible, move responsibility into services that live outside the framework.

In our particular case we’ve done all of the above and have managed to build a stable system with respectable test coverage.  We’ve also engaged the vendor to see if they can modify some of the framework interfaces to simplify unit testing, and they have been open to our suggestions.

For the last 2 months, we’ve been using ControlTier to automate deployments to our integration and QA environments.  Our deployment is a little more complicated that most Java applications because it runs on a pseudo-grid.  That is, there are 2 clustered JBoss servers, a database server, and 4+ Linux servers that each run about 8 Java processes.

I was able to get ControlTier up and running in a few days, and defining the jobs was relatively straightforward.

1. Automation is good.
2. People make or break a project. Thanks Joel.
3. Coding the right tests is hard, but infinitely valuable.
4. “Cutting edge development” describes the processes and principles, not the technologies.
5. Software must be tested in a representative environment.
6. Knowing the gaps between marketing and reality in your vendor’s software is valuable.
7. The timing of a discussion directly influences its outcome.
8. Metrics are useful but can be gamed.

Deploying a sufficiently complicated application into a corporate environment involves navigating a sea of paperwork, getting all the appropriate “approvals” in place, co-ordinating with department managers to get time slots from their staff, and so on.

Knowledge silos

On Release Day all the right people from the various departments - DBAs, application server administrators, server administrators (both Windows and Unix), desktop support, storage experts - are all sitting in their cubicles at the allotted time waiting to check their checkbox, waiting to mark their task as Done, so they can catch the 5:31pm train home.

I read a great quote in I’m feeling lucky. It described a note sent from one Google employee to another as he handed over a piece of software.

• Here’s what I’ve done.
• Here’s how it’s running.
• Here are some things to look at.
• Here’s what’s going to go wrong if it goes wrong.
• Here are the steps to turn it off.

These five points would be invaluable documentation to any new code or functionality. Imagine how much time could be saved if you had this information before embarking upon a code change.