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.

photo credit: Kecko

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

A few months ago, I got tired of ASP.Net.  I was tired of developers who depended on server-side controls, the Microsoft ajax implementations (as opposed to under-the-hood javascript ajax), excessive use of session and view state.  My preferred method of coding which relies more on the html than on the “runat=server” attribute, was considered old fashioned.

photo credit: paulb

So, I wanted to look at something else.  In my mind, Asp.net was getting too bloated and heavy.  I started learning Ruby on Rails.  RoR is a fantastic framework which integrates testability and maintainability.  Rails is the framework—Ruby is the language.  It’s easy to set up an Model View Controller site very quickly.  I love Rails, but I hate Ruby.  I had to lean how to do everything over again in Ruby.  It was like learning to speak a new language—even the simple things were hard.

Then, I looked at the ASP.net MVC framework that was released earlier this year.  The MVC framework is like Rails for ASP.  It keeps aspects of ASP.Net that I really like (like master pages and C#) and moves away from the bulky server-side, viewstate heavy, controls (like the DataGrid) that slow down ASP.Net performance.

My faith in ASP.Net is restored.  My brief foray into the hip and trendy world of Ruby development has given way to working on Microsoft code again.

I’ve been using the MVC framework in a few projects now.  I’ve started writing a Chinese Dictionary application (using the CEDict database) and am enjoying every minute of it.  I don’t know if I’ll every put this site live, but coding it is helping me learn the finer points of the framework.

There are some great MVC tutorials here:

http://www.asp.net/mvc/learn/

The best video tutorial (to start off with) is “Creating a Movie Database Application with ASP.NET MVC”.

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.

Scott Hanselman released a podcast a few days ago called “The Past, Present and Future of .Net Unit Testing Frameworks” where he collected a panel of the creators of NUnit, XBUnit, and other Unit testing frameworks.  It was an interesting listen.

http://www.hanselminutes.com/

The panel spoke of some of the shortcomings of unit testing that still need to be overcome. 

What I found the most interesting was not what was said in the show, but how difficult it is to find good developers who believe in test-driven development at all. 

One of the perks of where I’m working now is being able to work with talented developers again. I don’t mind the occasional solo projects, but you can learn a lot more by working in a development team. One guy I’m working with is very big into design patterns and I’ve actually become very interested in them myself.

I tried to learn some design patterns for C# about six months ago, but found them to be very complex. I was also working with some people who didn’t really see the point of them. The last contract I spent trying to convince the developers that they shouldn’t be using inline SQL in a page source. So, I didn’t have much luck learning it on my own very well. Now, I got loads of code to marvel at and compile.

When I mentioned my difficulty picking up Design Patterns to my colleague, he told me he had trouble with some of the concepts too until he read “Head First Design Patters“. He recommended it as a first book on the subject.

Head First Design Patters is a book about Design Patterns in Java, but the concepts all work with C# and seem to be the same GangOfFour patterns used by .Net developers.

The book is very easy to read and a lot more eye-opening than a lot of the other computer books I’ve read. If you are interested in learning Design Patterns, let me pass on my friends recommendation and suggest this book.