Comments on: The software design pit http://carsonbaker.org/2007/06/10/the-scourge-of-uml/ Thoughts on finance, robotics, embedded systems, and interactive art. Mon, 08 Sep 2008 15:39:52 +0000 http://wordpress.org/?v=2.5.1 By: Kristian Dupont http://carsonbaker.org/2007/06/10/the-scourge-of-uml/#comment-10 Kristian Dupont Fri, 15 Jun 2007 17:32:59 +0000 http://carsonbaker.org/2007/06/10/the-scourge-of-uml/#comment-10 I think that the engineering analogy (construction is often used as well) is at least part of the reason why people want to do up-front design. The difference is that software is intangible which means that you can change it even after you've made it, something that doesn't apply to the other fields. When you have that option it's simply better to rely on feedback than on design documents. In my experience, anyway :) Glad you liked the article, thanks for the link. I think that the engineering analogy (construction is often used as well) is at least part of the reason why people want to do up-front design. The difference is that software is intangible which means that you can change it even after you’ve made it, something that doesn’t apply to the other fields. When you have that option it’s simply better to rely on feedback than on design documents. In my experience, anyway :)
Glad you liked the article, thanks for the link.

]]> By: Neil Trodden http://carsonbaker.org/2007/06/10/the-scourge-of-uml/#comment-9 Neil Trodden Tue, 12 Jun 2007 12:35:47 +0000 http://carsonbaker.org/2007/06/10/the-scourge-of-uml/#comment-9 I just want to say I support your comments. I've spent too long agonising over whether a design will perfectly fit the solution when it would have been better for me to realise it won't work further down the line - and *change* it! Other than doing feasibility tests, there is no problem I am going to experience that cannot be re-factored or worked around. Bug-fixes and workarounds aren't always the horrific, unsupportable hacks people make out. I just want to say I support your comments. I’ve spent too long agonising over whether a design will perfectly fit the solution when it would have been better for me to realise it won’t work further down the line - and *change* it! Other than doing feasibility tests, there is no problem I am going to experience that cannot be re-factored or worked around. Bug-fixes and workarounds aren’t always the horrific, unsupportable hacks people make out.

]]> By: Andrew McVeigh http://carsonbaker.org/2007/06/10/the-scourge-of-uml/#comment-8 Andrew McVeigh Tue, 12 Jun 2007 11:36:58 +0000 http://carsonbaker.org/2007/06/10/the-scourge-of-uml/#comment-8 Although there is an element of truth in how you regard UML as boxes and lines, the concept of design in engineering, even for software, is far more important than you make out. You need to make the level of design (and formal verification) consistent with the danger of your system not working. i.e. if you are developing a CRUD application for your local tennis club membership, then no design or verification is really required. You can just rely on your intuition, judgement and the logical power of your own mind. However, looking to the other end of the spectrum -- design is critical if the application is critical. For instance, consider the software that runs a pacemaker or an insulin injection device. How would you like the software to be faulty just because noone thought of that particular condition? This is where formality and design is very important. There are many other points in between which require degrees of modelling and less rarely verification. For instance, in very large systems which have to be divided up into systems-of-systems, it is vital to have an architectural model or the whole thing falls apart. I've seen it work both badly and well depending on how the architectural design was communicated. All other engineering professions use modelling. E.g. who would build a bridge without determining it could hold the stresses? Only an incompetent engineer. The fact that in general people think that we don't need these techniques shows that: 1. software is still a very low productivity field, that is in its infancy in terms of organisational and delivery capacity 2. the formal and design techniques haven't risen to the challenge of being low in procession and easy to grasp but still rigorous Andrew Although there is an element of truth in how you regard UML as boxes and lines, the concept of design in engineering, even for software, is far more important than you make out.

You need to make the level of design (and formal verification) consistent with the danger of your system not working. i.e. if you are developing a CRUD application for your local tennis club membership, then no design or verification is really required. You can just rely on your intuition, judgement and the logical power of your own mind.

However, looking to the other end of the spectrum — design is critical if the application is critical. For instance, consider the software that runs a pacemaker or an insulin injection device. How would you like the software to be faulty just because noone thought of that particular condition? This is where formality and design is very important.

There are many other points in between which require degrees of modelling and less rarely verification. For instance, in very large systems which have to be divided up into systems-of-systems, it is vital to have an architectural model or the whole thing falls apart. I’ve seen it work both badly and well depending on how the architectural design was communicated.

All other engineering professions use modelling. E.g. who would build a bridge without determining it could hold the stresses? Only an incompetent engineer.

The fact that in general people think that we don’t need these techniques shows that:

1. software is still a very low productivity field, that is in its infancy in terms of organisational and delivery capacity
2. the formal and design techniques haven’t risen to the challenge of being low in procession and easy to grasp but still rigorous

Andrew

]]>