Archive for the ‘Architecture’ Category

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.

Daunting.

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.

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

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.