After several years doing software projects, we have started to learn what it takes to make them successful by using agile techniques, but what is providing the agility when the project is complete? Are successful projects equivalent to successful software?
I strongly believe that there is great untapped winnings in really learning the true nature of software and how to relate to it.
A big number of leaders, and unfortunately developers, are neglecting the fact that software has quite unique qualities that one can’t translate from other well-known and more static areas, such as construction.
The negative consequences for companies can be huge – the five-year old successful project has now become a ball and chain. Increasing the number of resources does not give the desired result. New business opportunities presents themselves, but the company is unable to act on them because they are busy in just keeping the systems operational from day-to-day.
It is just a matter of time before the smaller and more lightweight companies have left you behind. Now the solution thrown at the problem is “the big rewrite” – building things from scratch, which is in itself a high risk project.
I believe this is very common, in some way or another, in a lot of companies today.
Why aren’t we trying to identify and handle the root causes to this? It seems that we have unconsciously accepted that this is the life cycle of our systems.
Essential for strategic systems
What I am talking about is extremely important to address for your strategic systems (Fowler: Utility vs strategic). Strategical systems; your core business – your differentiating factor.
The external factors should hopefully already be covered by management (economy, staffing, etc) – these are areas that are concrete and well-known.
The other internal factors are not so concrete and visible for management – does this mean that they are not there? Is controlling the projects budget more important than controlling the need for a new “rewrite-project” in 5 years? Is the CTO focus on licensing-cost, infrastructure and technology more important because it is more concrete in the short-term?
It is hard to compare them, but in my opinion they are both very important.
We know how to check if we are on budget, but how do we check our systems?
These are a set of randomly selected suggestions:
- What size are the systems modules and which principles are they built upon?
- How do they relate to each other?
– Communication, time and space coupling, data sharing, interoperability
- How autonomous are the modules?
- How does the modules and their interaction reflect the real business?
- What are the strategy for keeping complexity low over time?
- How to keep it flexible?
- How to avoid “software rot”?
- How to increase speed despite the increasing number of features?
Technology is not the main focus here, also you know you can’t predict the future, so thinking of everything upfront wont solve anything in the long-term perspective.
The Brundtland commission has a really good definition when talking about sustainable development:
“Meets the needs of the present without compromising the ability of future generations to meet their own needs.”
The world has eventually recognized this extremely important consideration at the macro level, when will the software industry start to recognize – and act upon it?
First and foremost, accepting that this aspect exists will get you half the way. Talk to your development teams or architects about this. It is unfortunately common that they have too much of a technology focus. Most probably, both management and devs need to learn more about this aspect of software together.This is based on a previous post which I wrote for my employers blog (in norwegian): http://blog.amende.no/index.php/2012/01/vi-ma-laere-oss-software/