A good article was posted yesterday by the ComputerWorld Website saying that the leading cause of software project failures is the complexity of the applications.  The article quotes software architect Roger Sessions:

“Our goal should be to design the least complex architecture possible that solves the business problem”

I’ve been part of many projects that were mired in complexity.  They usually over-run or we end up with a sub-par system that awaits a never-to-happen refactoring and revision.

It’s easy to brainstorm a project and add feature-after-feature until you produced a project plan which stretches over months or years.  It’s easy to design an interface that looks like a cockpit dashboard with lots of functionality that you will probably never use, but looks impressive in the way it fills the screen.  “Wouldn’t it be great if this interfaces with every other system we have?  Wouldn’t it be great if we could use that new transactional system that’s really hot right now?  Wouldn’t it be great if . . .”

I’ve been guilty of this in the past—but I’ve been burned so many times that I tend to err on the side of simplicity (but I don’t always get final say in architectural decisions).

Over the past few years there has been a move to simpler architectures, simpler interfaces, and quicker release cycles.

Scrum is an agile methodology that stresses frequent releases over many iterations.  So, at the end of each 2-3 week iteration, you have working software—regardless of whether you release it to the public or hold until the next iteration.  It’s a methodology that resonates with a lot of people who have worked on failed projects in the past.  I became Scrum Master certified a few years ago, and it changed my whole view of how projects should run—but it is not easy to convince business owners to go this way.

37 Signals released a fantastic e-book called “Getting Real” which they stress that building software is more important that talking about building software.  They have released one of my favourite on-line apps ever with Basecamp.  It is quick, easy, and has a simple interface.  They refuse to clutter it every bit of functionality anyone asks for.

Interfaces in general are getting more simple to use—and not just for products like Basecamp.  10 years ago, you had apps that tried to fill your entire browser with things to do, but now you see more and more that are intuitive and easy to use.  Compare Yahoo! (with a browser window you couldn’t find any blank space on) with Google (a textbox and a button—no manual needed).

The software that has a better chance of reaching “finished” is the software that keeps the architecture simple, keeps the interface simple, and releases frequently.

Here’s the link to the ComputerWorld article:  http://www.computerworld.com/s/article/345994/The_No._1_Cause_of_IT_Failure_Complexity

There have been a few times when I’ve been talking to developers or even IT managers when they’ve tried to explain their poor planning by saying that they are practicing Agile development.

Agile is actually a pretty regimented system.  I took a Scrum course last year to become Scrum Master certified.  It opened my eyes to how software should be developed.

If you’ve never heard of Scrum , there’s a very quick overview of Scrum called Scrum in Under 10 Minutes posted at YouTube.  It’s pretty good.  Have a look.