A lot of people are talking about a software development renaissance right now. The reason for this may just be that we can now identify so many more of the problems we face with software development and see where we are going wrong – we can also identify the very fact that they are happening and causing ill effects inside businesses.
Here’s a snap shot of some recent industry figures – these figures change constantly and different analyst houses jostle with each other to try and update and refresh them all the time. But they’re always around these
levels (at least they have been for around the last five years anyway), so have a quick glance:
◆ 53 per cent of projects have cost overruns of more than 50 per cent
◆ 68 per cent of projects have time overruns of more than 50 per cent
◆ 31 per cent of projects are cancelled
◆ 16 per cent of projects are a success
◆ 54 per cent of projects are missing 25 per cent of their specified features
Here’s a theory that explains why we are about to feel the effects a renaissance and a new technology era:
The first era was the ‘build’ phase. This was the structured architecture era of the late 60s. We’ll call this the Roman period. Programming was in its heyday and software development was falling into comfort zones where procedures may not have been totally efficient, but at least they were ‘predictable’.
The second era was the ‘compose’ phase, this was the age of components and objects and databases and this we’ll to call the Gothic period.
So to the renaissance, the stage of evolution we’re find ourselves in now. This is the ‘improvise’ era, the age of agents, active objects, infrastructure and adaptive systems. This is a renaissance because it represents a traditional break from the past in terms of the way we approach software development.
The key challenge here for developers working in the renaissance age (if you buy the analogy) is that they have to move to a more abstract way of thinking.
Within the renaissance approach to software development, we need a re-rationalisation in the way we regard traditional methodologies.
The issue here is illustrated with the example of our fictional network manager who, when asked to describe and define a ‘user’ said he or she was, “Someone who degrades the performance of the server.” The renaissance is about not thinking like that.
As is my usual method, I asked a few punters for their opinion on this topic – here’s what a couple of the big boys said:
“Fundamentally, we are only just emerging from the ‘build’ era. We are only just truly starting to realise that we can’t carry on ‘ripping and replacing’, that building new apps to replace the old never truly succeeds resulting in a mass of aging, inefficient and ineffective systems. This is why SOA has come about, aiming to provide a way to connect systems which are open, uniform and interoperable. If done successfully, SOA will extend IT investments by creating new from old,” said Matt Deacon, senior architectural advisor, Microsoft UK.
Deacon continued, “If the next phase of software evolution is to be a ‘renaissance’ then it should be far from being about ‘improvising. To be successful and enlightened it requires learning from previous approaches, leveraging and extending the technology that already exists and applying it the context of new and emerging requirements. If one incorporates visions of the Internet then this is really about taking SOA global. At Microsoft we refer to the phrase ‘Software plus Services’ to describe our strategy in this era as we look to bridge between software on premise software and services on the cloud.”
Now to Big Blue
"The wave of Service Oriented Architecture, where businesses need better flexibility and more reuse of systems and services, has created a radical shift in vision of what is needed. We were in an era of function oriented prolonged development cycles using components and objects with long-term investment. We are now entering an era of process oriented, build to change orchestrated solutions using services and short-term investment. The emphasis is on the integration of people, processes and information in a responsive way and drives approaches such as agile programming, mashups, and social networking,” said Kevin Malone, software technical strategist, IBM.
Malone also continued, “The approach of using a large application package to solve IT project challenges has not had the desired effect - and the innovative notion of a business process being the application of the future and it being directly deployed using appropriate available services (internal or external) is resonating with many. Although approaches are changing, there is still the need for highly available, robust, scalable, secure systems and a collaborative application lifecycle management approach is vital to achieving this."
Moving on, or slightly to the side at least, with this discussion… some sources are ‘defining responsibility’ as the process that IT professionals must now embrace in order to become an effective part of the technology function.
Using our ‘through the ages’ analogy again but from a different perspective - the period during the start of the nineties can be argued to be the age of ‘inevitability’, when the majority of IT progress was related to increasing processor performance and straightforward client-server structures.
Into the mid nineties we experienced the age of ‘reason’, when customers starting looking more closely at the size and structure of their solutions and questioning to what degree they could benefit from bringing in more bespoke elements IT infrastructure.
Then around about 1999 came the age of hype, this of course was the peak of the dot com bubble when venture capital was pouring into poorly developed business plans as investors were keen to capture every technologists’ inspirational idea, or run the risk of not backing ‘the next big thing’.
After the IT market bubble burst and the age of hype quickly started to fade into pre-history, then came the inevitable age of disillusion.
So now we turn to the current age. Not the 21st Century, but the age of responsibility. This is about building trust with customers; and this only comes from producing technology that reflects principles such as openness, competence, integrity and consistency.
I hope you buy into my hypothesising, I think there’s something in these arguments. You may not agree with all of this, but I know you’ll agree that software development is constantly evolving, so surely we should take a high level view from time to time and try and identify some trends. This way, we might just be able to learn for the future right?