3 ms·

I wonder if you would dare say the same on other engineering blueprints.

• fleitz 16y ago
  Good 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 ago
    It 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 ago
  Engineering 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 ago
    This 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.