I want to highlight this particular link, “Top Ten of Programming Advice NOT to follow” [sic]. Except for #10 (throw exceptions), every one of these suggestions flies in the face of what programmers are traditionally taught. The general complaint that the author makes (suggestion #1) is that design is overrated. Start coding instead! I completely agree, with only a few provisions. Take time to think about what’s going on, but don’t waste valuable time creating formalisms.
Unless you’re working for NASA, you probably don’t have to prove your invariants—so stop pretending. If you understand the problem you’re approaching, and you’re competent enough, you’ll quickly figure out a reasonable way to get there. Even if you make mistakes along the way, who wants to bet it’s easier to correct them after the fact, when everything is set out plain and clear than it is to try to nail the solution the first time around. Think about the tradeoff you make everytime you draw a UML diagram. Is your careful planning really saving development time? No, you’re massaging yourself into delusion—your model isn’t robust; you’ve ignored the implementation details; and now you have to manage another component of the system.
Let’s think about the evolution of software design over the past decade and try to draw out a few points. In the beginning there was assembly, of which the function call pattern was a design issue. C made it obsolete—you had to use it. Then the theorists spent their time lecturing on the OO paradigm, writing books, and generally coercing the masses into its adoption. C++ obsoleted that. Since then, further refinements in the way we program have transpired, giving rise to Java, C#, and agile techniques. So at least for the moment, the issue of design has been resolved. Given the hardware we currently use it seems unlikely that there will be any new paradigm shifts. Oh no. What are the authors, the theorists, and the managers to do?
Here’s a challenge: find all the software design books of the past few years and look up the author’s biographies. How many still regularly program? It should be surprising, except when you realize that there’s a lot more money in consulting than in actual programming. I’d say most of the “top ten” advice you get when you read about software engineering should be taken about as seriously as your horoscope.
Yet although they’re obnoxious, I don’t see the designarati as the reason people fall into the pit. To me software development is an art. It requires practice and learning by example, also by doing. And it’s a subjective thing; what works for you may not work for someone else. The important thing is think a little about what makes sense and then get to work. You can’t preemptively design your way to a solution. It’s a premature optimization of the very worst temptation.
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
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 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.