The Seven Deadly Sins of Software Application Development – Parts 1 and 2
Posted: July 3, 2008 Filed under: Uncategorized Comments Off on The Seven Deadly Sins of Software Application Development – Parts 1 and 2An excellent pair of postings regarding software development from Lorne Cooper.
Diverse Teams and The Law of Requisite Variety
Posted: October 5, 2007 Filed under: Uncategorized Comments Off on Diverse Teams and The Law of Requisite VarietyIn 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
Posted: August 27, 2007 Filed under: Uncategorized Comments Off on Subcontractor BluesSome lessons I’ve learned from working with prime contractors.
- Never sign a ‘final’ copy of a contract without comparing it with the ‘draft’ copy that you’d agreed with the prime,
- Stick exactly to the scope of your contract,
- Don’t make any comments, positive or negative regarding anything outside the scope of your contract,
- If you’re selling software as well as services, get payment for the software before you do any work on a project,
- Never go outside the scope of your contract even if the prime has made the whole project fail,
- 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?
Posted: May 27, 2007 Filed under: Software Architecture Comments Off on 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 –
- Spec – > Design -> Code and Fix
- Rational Unified Process
- Agile methods
I’ve come to a few conclusions, which I call Marks Philosophy of Software Architecture:
- Listen to what other people have already learned,
- Always listen carefully to alternatives to your own proposal,
- let the technically superior alternative win, even if it’s not your own,
- Manage risks!