Embracing Change

When I consider the "agile software development methodology", a key principle that comes to mind is "embrace change". The theory is that users don't really know what they want. They'll only be able to steer you to the goal once they see something working. So get ready for change. They'll change their minds a bunch of times as the software evolves. In the end they'll appreciate your flexibility to adapt the software to their changing vision and you'll be a happy developer because you've created something that will actually be used and appreciated by the end users.

But what happens when it's your team leader who keeps changing the technologies under your feet? Is it just another kind of change to be embraced? Let's see...

The elaboration phase of the unified process can be defined as: "This phase attempts to create an executable architecture that realizes architecturally significant use cases." In other words, we should select the appropriate technologies that will be needed to create a solution for the most difficult known use-cases and then actually prove that our chosen technologies will do the job by creating executable software. Then during the construction phase, we should be ready to tackle the problems (known and yet to be discovered) with the technologies in hand.

A second core principle of the "agile software development methodology" is "You aren't going to need it", which means you shouldn't overengineer something because you think you might need it in the future. Keep it simple. The idea is that you save time by not doing it now and you make your code better and more maintainable because it's simpler. If someone ever says to you "if we build it in now, it'll save us time later" and you already have too much other work to do right now, then tell them to forget it.

I'm currently in an environment where every "senior" resource is on a mission to turn the management spotlight on themselves and the way they try to achieve that goal is to way overengineer the solution with as many Java frameworks as possible. By doing so they can prove their technical merit with a complex solution. To give you an idea of what I mean consider this:

We have a framework for dependency injection, we have one for database persistence, we have one for role based security, and one for binding XML, we have one, no wait two (or maybe three) for doing UI. We're in the process of adding yet another Java web container (without retiring the previous two) and have added every conceivable open source code measurement and style checking software. We have two continuous integration servers and in addition to the JUnit testing framework, we're adding Ruby/Watir testing too...

Individually and maybe with some intelligent selection I don't have anything against most of these frameworks (except for Spring) but after six weeks of development with 9 programmers with only a login screen to show for it, I say enough is enough. Java web development may not be as productive as it is with Ruby on Rails, but it's not this tough!! Come on! Look at the requirements and choose proven frameworks that address problems you've identified and don't cost more to implement, learn and maintain than it would cost to create a custom solution. For example, if you have to spend more than a couple weeks implementing a role based security framework when nobody has actually said you need to worry about different roles, then you're probably doing something very wrong. Keep it elegant, efficient and simple.