The Seven Deadly Sins of Software Application Development – Parts 1 and 2

An excellent pair of postings regarding software development from Lorne Cooper.


Diverse Teams and The Law of Requisite Variety

In a project meeting the other day with a client, I was asked why I had said I was pleased to see a mixture of non IT graduates on the project. At the time I just gave a rather facile “Its nice to get a diversity of viewpoints” kind of answer.

A bit of digging turned up W. Ross Ashby, and his ‘theorem’ that

Only variety in a system itself can successfully counter a variety of disturbances in the environment.

Makes sense to me.


Subcontractor Blues

Some lessons I’ve learned from working with prime contractors.

  1. Never sign a ‘final’ copy of a contract without comparing it with the ‘draft’ copy that you’d agreed with the prime,
  2. Stick exactly to the scope of your contract,
  3. Don’t make any comments, positive or negative regarding anything outside the scope of your contract,
  4. If you’re selling software as well as services, get payment for the software before you do any work on a project,
  5. Never go outside the scope of your contract even if the prime has made the whole project fail,
  6. If you hire anyone onto your team, make sure you get them to sign a non-compete clause to prevent them trying to go around you.

Reading this list, it all sounds pretty negative. If I’d had anything positive to say about working with a prime contractor, it’d be here!


What does a Software architect do?

How about: Guiding a diverse group of people through the conception, creation and deployment of complex systems.

Learning how to do this is not really something that can be obtained by study alone – learning to be a software architect comes about from making practical choices, often against a changing political and technology scene.

After years of designing systems, using a mixture of methods –

  1. Spec – > Design -> Code and Fix
  2. Rational Unified Process
  3. Agile methods

I’ve come to a few conclusions, which I call Marks Philosophy of Software Architecture:

  1. Listen to what other people have already learned,
  2. Always listen carefully to alternatives to your own proposal,
  3. let the technically superior alternative win, even if it’s not your own,
  4. Manage risks!