Self Inflicted Pain September 22, 2006
Posted by craiglp in Corporate IT Life.trackback
Over the past few months, the development team I belong to has been working on a variety of team objectives whose goal is to improve our ability to write better software. It’s hard to disagree with such a thing, in theory. The objectives revolve around unit testing (my group), automated build/continuous integration, programming standards/code review, documentation, and system deployment process (me again). The unit testing group I am part of has so far produced a four page ‘best practices’ document related to unit testing and using JUnit. We plan to next hold two classes on JUnit and writing testable classes. We are trying to keep it lightweight and focused on the goal, improved unit testing. The only tool involved is JUnit, which we are already using. K.I.S.S. The automated build team is sticking with basic, well proven tools and techniques (Ant and CruiseControl) to build the beginnings of a continuous integration process. The coding standards/review team started off okay. They based the standards on the Sun Java standards that have been around for several years. Then, they ran off the road and into the weeds. They included PMD as part of the coding standards/review process, good choice – no complaint. Then they hit upon a code review tool that they demoed in our team meeting. This ill conceived mess of a program/process was something only a disengaged manager would love. It is cumbersome, tedious, and intrusive. It’s everything a software development tool shouldn’t be.
The same story can be told of the documentation team and the deployment team. These were all good ideas, but in the majority (3 of 5) of the teams, the original idea was lost and committee thinking took over. Gartner Group teleconferences were held, software vendors questioned, parent corporation white papers considered. The end results are more red tape, less time to produce good code (or any code), and happier corporate management. Who is to blame? Ourselves, the developers. The lure of more tools, the ‘perfect’ process, and the desire to make a ‘big’ impact all played a part. I’ve heard the phrase ‘Agile development’ thrown about the office many times (not to mention SOA, and other buzzspeak), but we as a team, and company keep heading the opposite direction.
It seems that simplicity has no traction in the big corporate IT world.
Simplicity is one of those luxuries reserved for people in the upper echelons of the corporate world. Look at most CEOs, and you’ll notice they don’t wear a phone on their belt, and half the time, they don’t know how to use it, or their computer. They spend a lot of time on ebay or sports sites when they’re at work, and the rest of the time, they’re golfing. Theirs is a simple life.
Underneath them, you have directors and such, who carry all manner of hardware on their belts. Sometimes they do it because they’re enamored of the hardware (witness the glazed looks in the eyes of Blackberry users), and they claim (legitimately or not) claim it helps them to do their jobs better. In any event, they seem to like being connected 24/7.
Next level down, you have the middle managers/team leads/etc., who carry the cast-offs from the level above them; those crappy little pagers with the flip-top lids. They HAVE to carry those devices, which beep and vibrate every time a server poops its pants. Theirs is not a simple life.
Where the hell was I going with this? I’ve lost track.