Nelz's Blog

Mah blogginess

Contract Consultants

We’ve got an enterprise consultant in the office now. Generally, I think it has been a good thing. The consultant has helped the organization realize some important learnings, and has given good direction and insight on many topics.

However, there are two things that irk me about this process:

The Code

I am not impressed. I don’t want steal recognition of the consultant’s many contributions, but the code is not all that good.

We’ve chosen a decent stack in Hibernate, Spring, and (my least favorite part) Struts 1.X, and the consultant cobbled together the first set of template code to show all 3 layers working together. I’ve used Hibernate and Struts 1.x before, so I know them. With that I also know that Struts is kind of a bear when you talk about unit testing and XML-hell. I am the least familiar with Spring, but I love the Inversion of Control (IoC) and Dependency Injection patterns.

So, one day I am trying to adapt a copy of the template Action class he had for us, and I was getting kinda frustrated because it involves some inline instantiations and other non-testable bits. So, I Google’d for "struts spring". The #1 hit on Google was for this fantastic IBM Developerworks article on using Struts with Spring. I love this design, and am trying to get it adopted in our new codebase. But why wasn’t our template code using this? Why are we doing in-line instantiations? The answer: THERE ARE NO TESTS.

The code was developed by the consultant in isolation. The code was developed with no testing other than manual functional testing being done. The consultant went to great lengths to implement some security functionality in servlet filters, but without any tests, the code was not written to be testable. And, since there are no tests, any changes or piggybacks we make on this code may be breaking something. And since the code wasn’t being written for testability, the consultant never realized the architecture needed to be tweeked to use Struts/Spring helpers that I mentioned above.

We have been left vulnerable. We were handed "starter" code that already had a debt associated with it.

"Identical" Environments

Another thing the consultant is pushing for, and management has swallowed, was the need for every developer to have exactly identical environments. This drives me nuts!

Software engineers are pretty bright, especially when it comes to their IDE’s. They should be allowed (and expected) to customize their environment as they see fit. Sure, make a paper standard, and expect all documentation to be written from that standard point of view, but allow the developers to have unique plugins installed. Enforcing mono-culture is kind of silly, and robs the developers of learning how to configure plugins in their own environments. Having several different environments in the mix helps to keep everyone honest and functional. (You can almost think of each developers workstation as yet another test environment, and if they are all working, then your system is fairly robust.) And while sometimes the my-environment-vs-your-environment troubles are frustrating, they can also yield some deep understanding and learnings about your systems as well.

Big Picture

All in all, I think having the consultant around has been mostly positive, yet what I’ve mentioned above are my caveats. If I ever do pursue independent contracting in the future, I’ll try to keep these lessons in mind…

My bigger question comes to why the organization felt they needed a consultant, especially for the coding part? Many of us were already pushing for us to travel down some of these paths, and I think our code would have been much better than what he produced. Does an outside opinion really weigh in heavier than internal wisdom or experience?