Monday, October 19, 2009
Software Design Review
I'm a regular reader of a Philip Greenspun's blog.
He has written an interesting article on the subject of 'Software Design Review'.
The problem he tries to tackle is a classic in the field of software development: how can non-technical management manage a software project. It sounds a bit silly, but it really is a problem.
Small and large software project all over the world fail miserably for years, and still are failing.
From small 'in company' projects, to big government funded undertakings, the reality anno 2009 still is that these projects are delivered not in the given time budget, often perform poorly, do not function properly, etc...
Philip Greenspun's argues that the software development process is too opaque, and that it needs proper third party design review at the start, during and at the end of the project.
It's an interesting proposal, and it it can be seen as having an external technical on-site stakeholder present all the time. This certainly makes sense, as I agree that a lot of projects are suffering from a lack of focus, and regularly a re-calibration of the business goals is healthy to spot problems early on, and deliver on-spec, on-time, on-budget.
However I do taste quite a bit of bureaucracy in the proposal, with al lot of documentation that has to be produces during all the steps.
A lot of outsiders to the field tend to compare software building, with real building (like in a building a house). But this analogy doesn't hold true.
First of all, software is not build from ready made, fully specced, 'parts' Nobody guarantees you anything when talking about 'software parts'. Some have SLA's, but even then a lot of things are 'unknown', 'not tested', 'never tried', 'fixed in next version' etc...
Experience also learns that it is very hard to have a fully fleshed out and final design before construction, as the 'architecture' tends to evolve based on changing requirements. This is why the Agile development practice leads to better results than the Waterfall method.
But I do support the call to lift the practice of software development to a higher level. And being both a software developer and running a business, I also do think that the practice of developing software needs a more formal methodology, and lead to more predictable results. ¶ 22:04
He has written an interesting article on the subject of 'Software Design Review'.
The problem he tries to tackle is a classic in the field of software development: how can non-technical management manage a software project. It sounds a bit silly, but it really is a problem.
Small and large software project all over the world fail miserably for years, and still are failing.
From small 'in company' projects, to big government funded undertakings, the reality anno 2009 still is that these projects are delivered not in the given time budget, often perform poorly, do not function properly, etc...
Philip Greenspun's argues that the software development process is too opaque, and that it needs proper third party design review at the start, during and at the end of the project.
It's an interesting proposal, and it it can be seen as having an external technical on-site stakeholder present all the time. This certainly makes sense, as I agree that a lot of projects are suffering from a lack of focus, and regularly a re-calibration of the business goals is healthy to spot problems early on, and deliver on-spec, on-time, on-budget.
However I do taste quite a bit of bureaucracy in the proposal, with al lot of documentation that has to be produces during all the steps.
A lot of outsiders to the field tend to compare software building, with real building (like in a building a house). But this analogy doesn't hold true.
First of all, software is not build from ready made, fully specced, 'parts' Nobody guarantees you anything when talking about 'software parts'. Some have SLA's, but even then a lot of things are 'unknown', 'not tested', 'never tried', 'fixed in next version' etc...
Experience also learns that it is very hard to have a fully fleshed out and final design before construction, as the 'architecture' tends to evolve based on changing requirements. This is why the Agile development practice leads to better results than the Waterfall method.
But I do support the call to lift the practice of software development to a higher level. And being both a software developer and running a business, I also do think that the practice of developing software needs a more formal methodology, and lead to more predictable results. ¶ 22:04
