Are we stuck in our ways, or just out to make things complicated?

Here we are in the 21st century and whilst IT technology is moving on, is it possible that the main obstruction to moving forward is that we just dislike change? When I refer to change I mean as part of software / hardware project or implementation. We wrap change up in jargon, methodologies and documentation. We look at all aspects of the change; is it the right thing to do? who else has done it? can we check our thoughts with someone else? does everyone agree? We then document this process and write reports about the documentation. We generally make change quite a difficult and complicated process.

I don’t deny for one second that some changes need a plan to ensure success or chaos would rein. But is it possible that the more popular methodologies are overly complicated? Are they designed this way simply because the more complicated we make things, the better this makes us feel about changing? The core of most methodologies regarding change require documentation, consultation, meetings, follow ups and reviews. All of these generally require time; weeks, months and even years in some cases. Do we need all this extra time? or does it just allow us to adjust to the change? Are we using these methodologies in order to give us time to ‘get our heads around the change’ ? The longer a project takes, the more room there is for failure. The more people involved the more time is spent in meetings and consultation, and the more complicated a methodology the more documentation is required. Are we just making things too complicated for ourselves? If we made ourselves more open to change, and were bolder about change, would we still need complicated methodologies or would things be that bit simpler ?

This entry was posted in General. Bookmark the permalink.

4 Responses to Are we stuck in our ways, or just out to make things complicated?

  1. Mike Nolan says:

    Software engineering has long acknowledged the problem here, and while it’s still rife in large organisations – banks and central government are pretty bad – many companies are beginning to do something to change.

    Open Source development often goes by the mantra Release Early, Release Often, and I’ve been banging on about that for a while. Eric Raymond’s The Cathedral and the Bazaar is an interesting read if you have a few hours to spare.

    Ironically even these new programming methodologies are wrapped in jargon – XP (extreme programming), DRY (Don’t Repeat Yourself), KISS (Keep It Simple, Stupid), RAD (Rapid Application Development). All these on their own mean very little, but it’s a shift in attitude in the way you work with customers and the process of being open with what you’re developing.

  2. I’d say that generally that software engineers want to move things forward, change comes with the job. As you point out that are lots of new programming methodologies, but I’ve never seen a job advert asking for skills in any of them

    A quick look at the jobs pages today and there were 4 posts advertised for IT project managers. All of these wanted Prince 2 experience.
    Does Prince 2 guarantee success ? Apparently not !
    According to the research firm Standish Group contends that 90 percent of software projects are completed late, 66 percent are deemed failures and 30 percent are scrapped. Given this research it’s likely that at least 3 of the 4 project managers advertised for today will deliver the project late, at least two of them will fail and at least one of them will be scrapped. I’m glad I’m not applying for one of the posts !

    Going back to my original point, it does look like we are making things too complicated for ourselves. I’ve read some things about RAD and XP, we’ve even used a rapid prototyping methodology when building a few of the in-house systems. These methodologies are an excellent way forward, but a quick hunt through didn’t yield a single result for RAD, XP or anything along those lines. It takes time for the majority of people to accept change, if it didn’t methodologies like Prince 2 wouldn’t exist.

  3. Mike Nolan says:

    You’re right that there’s not an apparent market for these kinds of development techniques, but that’s not to say they’re not being used. It’s a hard sell to clients to say “we’re not going to give you any promises, but we’ll work with you throughout the process to ensure that you’re happy with what we do deliver”. But in the main those companies who have gone down the Agile route are happy.

  4. Al the Tog says:

    The KISS Principle dates from the 1960s and RAD started to be used in the late 1980s, so these have not stopped projects failing either. Some common causes of project failure are described in a very readable article by a company dealing in User Acceptance Testing (Coley:

    KISS, RAD, XP, etc., can help, but may not solve all your problems. Sound Change Management is also needed – I wouldn’t expect my bank to adopt the Release Early, Release Often approach for its Internet Banking system without some Extreme Change Management to go along with it!

Leave a Reply

Your email address will not be published. Required fields are marked *