4 ms·
These tools serve 3 purposes: 1. To make theory more closely match practice that already works. This gives teachers something to teach. 2. To make someone wh
by edw519 16y ago
These tools serve 3 purposes:
1. To make theory more closely match practice that already works. This gives teachers something to teach.
2. To make someone who doesn't know what he's doing appear as if he did. This gives consulting firms profitability.
3. To help organize the System Development Life Cycle (waterfall process) of very large projects. This gives someone who knows what they're doing a few more tools in their toolbox.
My take? If you've really found good use for tools like these, then your project is probably too big. Break it down into smaller pieces, build a prototype for each piece, get feedback, and refine. It's not how quickly you appear to get started; it's how soon you deliver something of value.
- shushan 16y agoI wonder if you would dare say the same on other engineering blueprints.
- fleitz 16y agoGood things are not designed in this fashion. I'm sure everyone else in the aviation industry used the uml equivalent, I'm pretty sure the skunkworks teams do not.
- shushan 16y agoIt was hard for the skunk works teams to use UML for a long time since it was only published in the late 90's, but what makes you so sure they are not using it now? or do you have a survey of which "good things" are not designed in this fashion? And besides what is the relative share of skunk works type teams from the overall software development market?
- deleted 16y ago[deleted]
- duncanj 16y agoEngineering blueprints are the "code". They are intended to be read in a systematic manner by someone who can put the parts together. In software, we call that someone a compiler. Design documents, such as sketches, artists renderings, specifications of performance, etc., may or may not be useful to the engineer producing the blueprint. The discussion of UML is at the level of these artifacts. If UML is useful, I want to look at it and have an idea of what the software is going to do. Some parts, like event-state diagrams, activity diagrams, and use cases, are pretty good at capturing that design in a way that I can talk about it with someone who doesn't understand code. I would not pay someone for completing a document like that, though, not until it was reflected in code. Another way of capturing design is through functional tests. Look at projects like Fit for examples of how that might work.
- shushan 16y agoThis is a completely philosophical discussion, but I do not think blueprints can be the code, since blueprints in every other industry still leave a degree of freedom for the final implementation and in the software industry code IS the final implementation.
- tjpick 16y agoMany software projects /are/ big. Many of them are complicated and monolithic, written by "someone else", unrefined, and quite possibly the first thing that they managed to get working. I find UML diagrams (sequence, class etc) invaluable for understanding code like this, as a reverse engineering tool. "An occasionally invaluable tool" is how I could describe UML diagramming.