Archive for August, 2009

As I’ve been saying, we need to change a few things around and some oganisation  things are already happening.

But that will only work if the people involved change their daily habits and mentality. It is perfectly possible to work within a RUP organisation and still maintain silos of knowledge where each developer is an expert in an area and work stops if he or she is not around. And I am yet to see a projet methodology that ensures real quality, rather than documenatation indicating it. It is easy writing up a long test script and showing the results, but does that ensure the quality of the application? Andwhat about the architectural scalability, and maintainability?

These things can only be addressed by changing the way the people involved in the project work and think on a daily basis. The quality we are after only comes from people caring about what they do and catching any potential issues early.

So we’ve started to use some practices that have been around for a while.

  • Test driven development for all new development, and legecy apps where it is possible. We have an architecture that is stopping us though, it is about 57 years old and using EJB’s that are heaviliy reliant on the application servers EJB container, and we dont have a test harness.
  • Continuous integration. At the moment, since we have that ancient EJB solution  this only makes sure the compilation does not fail. But its a first step.
  • Code reviews, from now on we’ll be peer reviewing any new release, both to make sure we get a second pair of eyes on it to validate the solution (we’re still not pair programming) but also to spread the knowledge.
  • Quality metrics. A touchy subject, but if we can clean up the code and use checkstyle, code coverage, static code analysis, we can get rid of some low-level checks we’re doing manually, and also get warnigns if the code base is losing maintainability.
  • Automating functional tests. At the moment all testing is manual, but with a little effort, each manual test can be automated and in time a full suite can be developed and our testers can do some real testing.

We’ve also started some discussion forums and a more formal quarterly meeting where we can discuss what w can do better to ensure we’re not staying static.  Since we have a relatively low staff turnover, there are  few ideas coming in from other industries and companies so in order to evolve we need to continuously asses, evaluate and adapt. And read a lot of blogs to find out what others are doing, of course…

So hopefully, these efforts will lead to increased communication on the ‘shop floor’ and an increased attention to quality and detail. And once the codebase has gotten a bit better, some knowledge is shared and with some automation in place, things can start turning around a bit quicker.

But most importantly, we can stop wasting time on activities that are non value adding and start spending time commuinicating instead. By using tools and practices sensibly to assess we are building things right we can start building the right things.

And thats nothing a process can help us with.