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.


I’m working with a lot of the Atlassian tools lately, and I do like them a lot. Though I know there are a lot of alternatives out there, I like the fact that these play nicely together and of course JIRA is a kick-ass tool. But enough of that.

I found a little annoyance in the latest fisheye release, which I wasted about an hour or so on.

We just decided in a moment of inspiration to use Gravatar to enable custom avatars, free, already comes integrated and seems easy enough to use. So we went off and created users and were careful to use the company email address etc and waited for the disclaimer amount of time to have it refreshed, but nothing happens. So I read a little more about it and think, maybe our firewalls are causing problems – I’ll use the HTTPS mode! I reconfigured and full of anticipation refreshed the people page, but again – nothing.

After ruling out general firewall and networks issues (I can see the image in a browser on the server Fisheye is running on) I looked closer to the URL itself, and it turns out the image source fisheye is constructing was not at all the same as Gravatar claims ot be using.

So I trawled through more of the details of both Fisheyes integration with it (not much), some forums, and how Gravatar generates the image itself and thats when I spotted a potential flaw..

"[…The next part of the URL is the hexadecimal MD5 hash of the requested user’s lowercased email address with all whitespace trimmed…]",

Noticed the lowercased bit??


We are using CROWD to feed the user details from AD, and even though we have set it up to only serve up lowercase output, that only formats users, groups and roles. Attributes like Email is still Camel case, and as we all know hashing is case-sensitive. But fortunately this field is editable in Fisheye in the local user details, so I can lowercase it myself – and Job done!

So while there has been a lot of thought and work going into this the devil is in the integration details.

Currently, we’re not really running projects to implement functionality. Its more like small requests which are usually undertaken by an analyst, a single developer and a single tester, loosly connected, but with very specific roles and responsibilities.

  • The analyst works with the business owner to formalize a specification and is responsible for the completion of the work on time and within budget.
  • The developer is responsible for implementing the functionality and ensuring that the release of the patch (usually we are working with maintaining existing applications) goes smoothly.
  • The tester is responsible for ensuring that the functionality described in the specification.

This is not an uncommon division of labour and there is no reason why this should not work however we are experiencing some problems.

  1. The requirements are usually completed without much involvement from developers or testers resulting in specifications that are incomplete and sometimes impossible or undesirable to implement.
  2. Since we are using a waterfall approach any problems with the requirements are discovered inside the development phase .
  3. Once the development starts the tester is usually disconnected and any subsequent changes that occur are not communicated and therefore not reflected in the test plan.
  4. Documentation is not coherent – each project may or may not provide documentation about the functionality and overall architectural documentation is scarce and out of date.
  5. Poor support for new joiners since the process and the division of responsibilities between the roles are not documented

This all leads to a lot of projects being delayed in various parts of the process, because they have to jump back up the waterfall, and that leads to our biggest problem. : There are too many projects going on at at the same time, with people working on multiple tasks simultaneously, and this is bad!!! Not only are there overheads for each person involved, but different projects have different staff so people are on several teams at the same time. That will lead to resource contention and prioritisation failure since no one is able to see the wider picture and therefore everyone optimises their own workload, even though that might lead to the entire chain (all projects) being less efficient (p 38 onwards of this book describes just that).

What this leads to is a lot of incomplete work that will have to be pulled last minute, a lot of rework because of poor communication, wasted efforts and inconsistencies – both in functionality and quality.

New methodology

To solve all these problems we have been working on introducing a project management methodology that will allow us to address these problems.

  • Flexible enough to apply for several different sizes of projects
  • Well established in the industry to ensure that new joiners will be able to grasp it
  • Enforce communication
  • Focus on Iterative and incremental development

How do we turn this agile?

Now, my goal is hand has always been to turn this agile, and to be completely honest we do have some practices and procedures in place that can be used, but there are ‘buts’

  • We have a backlog of ‘features’ (or various sizes of projects) , -but they are in different queues.
  • We are developing in a feature driven way , – but these ‘features’ or projects can be decomposed further
  • We already set up a team and project organisation around a ‘feature’ , – but teamworking is an issue
  • We have scheduled monthly releases and release what is ready when the date arrives , – but we frequently fail to meet the release date
  • We use source control and version management in this manner already , – but we only just started

Now this we can work with…

As a starting point, we have chosen to go with RUP, because

  • it comes with a nice set of role and responsibilities descriptions,
  • it has a large repository of predefined processes
  • it is much less contentious than ‘Agile’ and is likely to be approved politically
  • it can be scaled down enough to become Agile, and still please management in having a ‘phased approach’
  • there is some prior experience within the organisation, which will help introduction and learning
  • it will force us to document our systems in a coherent manner.
  • the focus on ‘team’ is strong, it will allow us to build a cross-functional feature team.

We’re basically thinking of the Dreyfus model here. RUP will be able to give ample support to take us through the Novice and Beginner phases, after that phase when we have learnt enough we can start chopping away the fat. And there will be a lot of fat to chop. In the initial incarnation the project manager and the architect will be inundated with documentation, so the first couple of projects will be slow and painful. But with each project we’ll start building up our repository of documetnation and the next project will get it slightly easier and we’ll soon have a decent view of our applications.

Rolling it out will start with with general presentations, so the entire organisation is aware of what is happening, and in agile talk, making us all pigs rather than chickens.
Once that is done, the nexts step is workshops for those involved in the early projects in order to get familiarised with the process. Hopefully this will reduce the friction within these projects and people would like to work in another RUP project once the first one finishes.
But these projects will also need a lot of guidance, hopefully we’ll get a mentor in to guide us through the first couple of iterations wh can steer us in the correct direction

This will no doubt require a lot of discipline and support by management. Hopefully, by setting the expectations from the start and making it clear what the benefit is will aid that.

I read this blog post a while back and it struck me as having a lot af lean elements to it.
I see a lot of similarities between balancing throughput, latency and variance that Beck describes and the concepts of muri, mura and muda and how it is used here in this entry about the toyota production system.

Increasing throughput in the way that Beck suggests is one of the ways of reducing Muri, and Becks conclusion of this leading to reduced variance is in line with the Toyota experience (mura translates to unevennes, inconsistencies). When it comes to latency, this is one of the types of waste that is muda and lean software engineering theories is set to eliminate.  (I recommend attending Alistair Cockburns webinars or reading Corey Ladas or Karl Scotland on this )

An unbalaced approach to these three legs will have detrimental effects on the other two, and thus the main objective is to optimize the whole. Its not about getting the highest throughput in develoment or achieveing zero variance. Its about getting all three legs to balance as Beck points out and that is what eliminates waste which is key in the Toyota production system.

Thats just what I read into it, I might be reading too much into it..
But at the moment i am trying to set up automated builds, continuous integration and deployment in my workplace in order to reduce our variance ( in quality) and increase throughput (by getting rid of manual builds and releases).

I was always thinking of this as a step towards getting leaner, and this post was a great encouragement…

I am currently finding myself in a team that I find is not reaching its potential or achieving even close to the results that I would expect from such a large team, with the experience available and the marketplace we are operating in. In particular I think that the interaction with other teams and departments, or lack thereof, is causing a lot of wasted time and pain. I have previously been working in agile teams and I’ve been reading a lot of material lately on agile methodologies and lean. I am trying to gradually steer our organisation towards being ‘flexible’, I don’t think there be a big bang approach to these things and I definitely think there will be strong resistance to such an initiative.

A brief background

The development team in which I joined a little while back has no real process, sure – one exists but it is incredibly convoluted and I am yet to find a development project that uses it.  What this ultimately leads to is that each project that is undertaken reverts to the informal, unstated process, or ‘the way things have always been done’.  The result of that is, perhaps as expected,  that the same mistakes are repeated and the improvement opportunities are being overlooked. During the last couple of years there has been some exposure to different methodologies, though these have been less than successful and inspirational.

The first one was a supplier who was pushing Scrum  who were involved in a project that eventually failed. Their failure to deliver sufficient documentation or indeed working code that matched the SLA was attributed to the methodology, rather than poor execution of it.

In more recent time a partner was involved in a long running implementation and with their experience in the  subject area came their preferred implementation methodology. The project did deliver functionality, though not all of it, and on time with a reasonable amount of issues for its size and as such was a success. However most people involved were not overworked and frustrated at the end and would not use the methodology again given a choice.

These two deterrents, combined with internal politics and the fact that turnover is rather low means that there is an innate resistance to change. This due to the fact that there is a culturally strong core that are comfortable with the informal process and protect it, while new influences are finding it difficult to get a foothold. I’ve heard this referred to as a hub and spoke model, an analogy that I find quite fitting with the hub concentrated, strong and central and spokes often unconnected and weaker.

The way forward

Turning this organization towards lean sounds insane, and in fairness it probably is but any movement, however small, in that direction will be beneficial.  I remember a conversation with a former project manager, and good friend, of mine a few years back when he was trying to do roughly the same thing. At that time we decided to shield ourselves, and create an ‘interface’ to the external stakeholders, and internalising those roles. While this approach worked rather well I feel is not adequate in this environment. Firstly we are interfacing with too many stakeholders and secondly bringing the teams closer and improving communication is imperative.

I think we are roughly talking about four major areas of change…

  • Introducing Project management. We have not really had any real project management on any scale, the lead developer has been taking on a lot of responsibility. Introducing a project management methodology that is well known and recognised by a large part of the developmet community which offers enough flexibility that we can incorporate agile or lean concepts. The methodology also has to bring the different parts of the organisation closer together.
  • Agile (Enterprie) Architecture: Another concept that has not been prominent thus far. The numerous application (in-house and off the shelf) are not working together and the continuous evolution of the architecture is not handled in an optimal way. Introducing an Enterprise architecture framework that allows for architectural agility and works well with the project management methodology is imperative. After all, for a software development organisation the architecture paves the way.
  • Introducing new practices: From the bottom up there are several problems in the development team itself which hinder agility.  Historically a lot of the work has been done in isolation with lmited knowledge sharing and communication coupled with a lack of attentions to principles like SOLID and DRY. For a sporting chance of successfully reaching anything resembling agile there are several practices that needs to be put in place.
  • Adapting the culture: Having frameworks and methodologies will get you a long way but the core underlying culture needs to embrace the nature of agility. The reluctance to leave the safety zone and try new ideas is a major hindrance, creating success stories in the small increments that I plan to bring these changes in are imperative.

I realize this probably has to be a gradual approach in several organizational layers at the same time, which is not making it any easier. The management need to adopt the project management and enterprise architecture efforts. Other teams need to buy into the project management methodology and the development team needs to work closer with these teams and change the way we work internally.


Fortunately there is a good deal of support throughout the organisation and I have no doubt that together we’ll be able to turn this thing around. At least its worth a try.

I just came across an interesting post about performace antipatterns in my RSS readerthis morning and I couldn’t agree more on 99.9 % of the contents.  There are two comments I feel are worth making though.

Layering is, of course adding extra noise to applications, but there are just so many instances where incorrect layering is causing serious quality problems. Big-ball-of-mud being one my peronal favourite among them.  A properly layered architecture should also reduce the number of WTF’s  per minute dramatically.

Reuse. In  a normal scenario, you’ll be doing several things in multiple scenarios, to keep yourself DRY, reuse is a must. Not only is this also a WTF/minute reducer but it aids in testability, development speed and consistency as well.

The quoute at the end sums this up nicely

Software reuse is a fine goal, but beware of violating the assumptions made during its development

The key points of this is that there are circumstances where it is necessary to trade some of the overall performance (in throughput) for quality and speed of development.



Just to drive the point home, guess what just brought down our latest release. A combination of Property accessor logic and not knowing what the underlying framework does, or does not do.

Now I believe this to be fairly harmless getter, we keep a history of dates and the current date is the first on in the list (its sorted). So if there is a list, and it has an entry, get the first one otherwise return null. Simple

 public Date getCurrentDate(){
        Collection dates= get(DATE_COLLECTION);
        return dates.size() == 0?null:(Date)dates.get(0);
  return null;  

The problem is only that when checking if we have a list,  it turns out the underlying framework hides the collection away in a hashmap. As a result in some instances the hashmap is touched by infrastructure code which adds a null to it, thus a check to make sure the returned collection is not null need to be in place.

There are three points here

  • Dont put frickin’ logic in proerty accessors
  • Know thy framwework, inside out especially if its hand rolled. You will not get maqilinglists with answers
  • There are good frameworks out there, so If you handroll your framework, make sure it doens’t do stupid things.

//End rant

In my rss reader there is usually a great deal of wisdom appearing each morning, and today was no difference. But its not often you get one of your problems, described in one and have it partially answered in another.

David Christiansen, author of the superb Technology Darkside blog tells this story, and I can see great similarities with corporate IT. In this case David talks about a dysfunctional team of consultants, but isn’t the same game played everyday in corporate IT? I think its called politics. So take those points and add

  • getting that senior-, specialist-, expert-, whatever added to your title,
  • creating endless cc lists on your email to prove you’re working hard and at the same time provide ass-coverage.
  • coming into the office while nearly-dead, since sick-days are just not for winners and of course
  • the hero anti-pattern.

All this, and many more, in order to keep climbing that corporate ladder. It takes a good manager to recognise these and the fact that they are counter productive and to take actions against it. One very effective cure to these things is to create total transparency to promote recognition by merit. The way Jurgen Appelo describes it here makes perfect and powerful point. One of my previous project managers didn’t actually post the salary spreadsheet on the wall but he threatened to and the effects were quite interesting.

But while this is very contentious, there is plenty of information that is not so and there are lots of tools out there today that makes information about your projects and product readily available. Why not let your continuous integration tool (you do have one, right?) generate a project report each night and publish it to the intranet. And while we are talking about that nightly build, it will break and when it does – make sure its very public, and slightly embarrassing. Project reports could also be public knowledge, which project managers are continuously over budget, which developers keep underestimating their efforts, which testers can’t find bugs? But more important than showing shortcomings, achievement can publicly proclaimed and rewarded. When the builds haven’t failed for a week, its the team leads responsibility to buy the first round of beers, or get that Friday sugar high going  creating that sense of collective achievement.

After all, until this information is in the public domain, how are you going promote recognition by merit? Lets  hope more
corporate IT departments are opening up to Agile and Lean, where
openness and teamwork is the norm.


Yesterday I came across  this on the daily wtf.

Generally I admit I default to adding getters an setters, quite often just to offer sacrifice to the java bean standards, even though this is very often just noise and syntactic sugar.  But I’m always wary when I see logic in a getter/setter, the example in this article is a fairly harmless one (as in its unlikely to break the application).  I’d be quite reluctant to do a redirect in a getter, thats just evil. Imagine trying to find that bug. The basis of that is that getters, when it comes to Java in particular, are so frequently used by ‘infrastructure code’ that you’re not 100% in control of (which of course Reflection is to blame for but that’s another story) . This opens up for way too many wtf’s in your everyday life.

I discovered this getter in a struts form the other day;

public List getDomainObjectList(){
return callMethodThatDoesIOAndAppliesBusinessLogic();


The struts form getter is called from a jsp, but since we’re also using apache commons reflection util to populate/scrape values from the form, and this field masquerades as a proper Bean property,this code gets called 3 times per page load. No wonder the error log is spammed with errors when the domain objects aren’t behaving.

And a few days earlier I had I discovered this piece of code, checked in over 3 years ago which just clearly does not do what it says on the tin

public void setExpired(boolean expired){


public boolean isExpired(){

	return this.userDetails().getExpiryDate()== null;

Now this is just poor coding, I know and this is nothing code reviews will not cure, but personally, I’d quite happily  do without these kind of surprises, which makes  removing the getters/setters all together quite attractive. They should most certainly come with a license.

The point is, if you are putitng any non trivial logic in your gettters and setters, you need to think long and hard about where they are being used, and then reconsider your decision.



This idea has been knocking around in my head for a while, but I’ve never really gotten round to it, which is a shame. I do have a lot of opinions about a lot of things that go in in  the weird and wonderful world of software development (and other things as well, of course, but they will not see teh light of day here) and when my collegue, after some email ping-pong, said ‘we need to get this guy an internal blog and set up RSS feeds instead’ I knew exactly what to do. And here it is, finally…

It is a bit daunting though, there are so many intelligent people out there who are ready to pounce on any mistakes and to be fair, I make quite a few. But what the… what doesn’t kill you make you stronger. So lets plunge in…