A few comments on your original question:I always try to approach a problem from a least two different directions. Part of that has to do with the fact that I've been programming long enough that, when I started, there was more emphasis on "getting it right the first time". By approaching a problem with at least two different perspectives, I would be more likely to notice possible problems with my analyses prior to design implementations.I'm under the impression that younger (especially new) software folks don't really worry about this so much. With modern, dynamic languages and modern software development environments, it is so much easier to refactor a design that they don't really see as much need to "get it right the first time". There are pros and cons to this newer approach -- I won't get into that here.Most of us have our own unique way of "seeing" the problem space. When I'm really "in the zone", whether analyzing a possible solution or executing the actual design, I tend to envision myself walking through sort of a three dimensional city of sorts, tyring to figure out what to do with an empty lot, or how to best connect two different locations or how to renew an older neighborhood or whatever is appropriate for the problem at hand.But other software people might think very differently. Some "see" the problem like me; most don't. In fact, in my experience, there is *no* dominant approach, so, no matter how a software engineer might think about a problem, he'll find that most people will not think about it the same way. Thus, one important skill is learning to communicate to others what you're thinking while you're "in the zone", while, at the same time, understanding what other people are thinking when they're "in the zone". People have developed various "standard" ways to do this (such as UML diagrams), but they're mostly useless (in part because they're typically constrained to two-dimensional diagrams, which is not how anybody is likely to think about any complicated problem). This communications problem can be exacerbated if people in different locations who have not worked together previously try to coordinate software design activities remotely.

QuotePeople have developed various "standard" ways to do this (such as UML diagrams), but they're mostly useless (in part because they're typically constrained to two-dimensional diagrams, which is not how anybody is likely to think about any complicated problem). This communications problem can be exacerbated if people in different locations who have not worked together previously try to coordinate software design activities remotely. The problem is not due to the fact that the diagrams are 2d; mechanical engneers have been using 2d CAD/CAM drawings for centuries to create productcs.The problem is due to the immaturity of the software industry and programmer intransigence. UML does not even get close to this.

There *is* a software engineering equivalent to the drawing you showed: It's software code. Software code is the equivalent of engineering blue prints -- the computer uses the code (in a compiled or interpretable format) to actually produce the finished product in much the same way that a mechanic or welder or carpenter would do with traditional blueprints.As you might expect, software engineers who are familiar with the same language have no problem sharing ideas through code. I can read code and "see" right away what the other guy was thinking as long as I'm familiar with the language he used. The deal is that, once the code is written, the software engineer's design work is already done (there is still testing and so forth, but the design is already done), so, depending on how a project is structured, it may or may not be useful when collaborating remotely (thus, an important part of running a project where some people are remote is structuring the project properly, but most project managers manage to mess it up).

QuoteOriginally posted by: eDaveThere *is* a software engineering equivalent to the drawing you showed: It's software code. Software code is the equivalent of engineering blue prints -- the computer uses the code (in a compiled or interpretable format) to actually produce the finished product in much the same way that a mechanic or welder or carpenter would do with traditional blueprints.That's one way to look at it, but IMO the analogy is incorrect. We need to distinguish between specification and execution languages.For the user the code is the (incomplete, usually) product. It is the developer's interpretation of the unwritten and implicit design blueprints.A mechanical engineer would not work in this way.

Suppose I wanted to draw a bouncing ball. I would say hmm,int theballheight = 0;Now I would like to draw the ball at that height. So I would draw a dot.int middleofscreen = 800;Plot(middleofscreen,ballheight);But that doesn't work, because what is plot? A ball is a circle, and a circle is a line that is equal distances from the center. But the height is the bottom not the center. The bottom is the center minus 10.int thecenter = theballheight+10;What the fuck do I do now? Well, the distance from the center is the square root of the X distance plus the Y distance.int screenwidth = 1600;int screenheight = 1200;for (int x = 0; x < screenwidth; x++){for (int y = 0; y < screenheight; y++){double xdistance = x-middleofscreen;double ydistance = y-thecenter;//erases absvalue code because we are squaring it anywaydouble distancefromcenter = sqrt((xdistance*xdistance)+(ydistance*ydistance));if (distancefromcenter > 9.5 && distancefromcenter < 10.5) Plot(x,y);}}See, it works, program is coming along nicely!

QuoteOriginally posted by: CuchulainnQuoteOriginally posted by: eDaveThere *is* a software engineering equivalent to the drawing you showed: It's software code. Software code is the equivalent of engineering blue prints -- the computer uses the code (in a compiled or interpretable format) to actually produce the finished product in much the same way that a mechanic or welder or carpenter would do with traditional blueprints.That's one way to look at it, but IMO the analogy is incorrect. We need to distinguish between specification and execution languages.For the user the code is the (incomplete, usually) product. It is the developer's interpretation of the unwritten and implicit design blueprints.A mechanical engineer would not work in this way.At some level, physical engineering disciplines have it easy because there's a one-to-one congruency between the blueprint drawing and the final object. Even a child can tell whether a blueprint (e.g., of a triangular peg) and an object (e.g., a round peg) do or don't match.. I'm not sure that software has any such analog of a design document that can be easily compared to the final manufactured object by a novice inspector.Yet there is a useful parallel, but it's really not at the blueprint level because blueprints encode a static object and software code is less like a static object as portrayed by a blueprint and more like a dynamic machine. So then the question is how do physical vs. software designers think about machines?Although physical engineering does use assembly drawings of completed machines, the functionality of the blueprint copy of a machine is often quite opaque and the machine's performance is virtually unguessable from the line drawing. For example, a drawing of a single-cylinder machine with a crankshaft, piston and two cam-operated valves might be a CNG/petrol/diesel internal combustion engine, a refrigerator compressor, or a water pump whose operating RPM and power level is almost unknowable from the drawing.The machine design thought processes for a mechanical designer starts with the top-level specification (e.g., design a diesel internal combustion engine producing 2 kilowatts at 1,800 RPM) and a very long list of secondary requirements (e.g., physical size constraints, interface requirements, noise emissions, exhaust emissions, ambient operating ranges, starter mechanism requirements, tradeoffs on cost, fuel consumption, reliability). An experienced designer (i.e., one who has designed many internal combustion engines would simply reuse an old design and merely tweak key characteristics such as number of cylinders, bore diameter, stroke, cylinder length, etc.). A design from first principles would be much more complex -- starting with the thermodynamic models of the combustion cycle and working outward from that. The thought process for the first principles design would essentially build a combustion process than then fill in the mechanical details required to support that process. It's also crucial to realize that a good designer would always be thinking of manufacturability (equivalent to understanding the compiler and available APIs) as well as the effects of manufacturing tolerances on performance.What's strange is that software may be a machine, but it's a very abstracted machine with no ready analogs to absolute or relative physical dimensions. I wonder what the CAD drawings of a physical Prime Number Machine would look like? And what might the CAD drawings of a physical SDE machine look like? Thinking about how to design an abstracted machine might be entirely different from thinking about how design a physical machine. Maybe that brings us back to the original point that physical engineering has it easy because the design documents are simulacra of the final physical product.

QuoteAt some level, physical engineering disciplines have it easy because there's a one-to-one congruency between the blueprint drawing and the final object. Even a child can tell whether a blueprint (e.g., of a triangular peg) and an object (e.g., a round peg) do or don't match.. I'm not sure that software has any such analog of a design document that can be easily compared to the final manufactured object by a novice inspector.That's interesting. I actually had thought of it almost the opposite way. One of the reasons I think that software engineers have it easy is because, given the blueprints (code), the final object is known because the computer (after a compilation or interpretation step) will execute the blueprints exactly as they appear. So to me, there is, in that sense, for software, a one-to-one correspondence between the blueprints (code) and the final object. True, you don't know ahead of time how the user or environment will interact with the software, but, for a given interaction, in a given state, you know (at least in principle) what the result will be. Consider physical engineering blueprints -- say, for example, an architect's blueprints for a house: Given the blueprints (a plan for a house), the final object is not known. The carpenters who build the house may or may not execute the blueprints exactly as they appear. In fact, in a typical situation, the carpenters will, here and there, intentionally do something that is different from the blueprints.So, while it might be easier for a novice inspector to read the architect's blueprints than it is for him to read the software engineer's blueprints (code), this inspector will have no idea if the house built from the architect's blueprints will actually be built according to the blueprints. On the other hand, he does know that software will be built according to the blueprints (code). That still leaves us with the problem you brought up: How is a "novice inspector" going to review my software design?In my experience, the usual solution to the problem of "novice inspectors" needing to review software designs has always been to generate "higher level" documents from the blueprints (code). Once one has code, it is fairly straightforward to generate higher level documents, in much the same way that a computerized architecture system might generate a high-level "walk-through" rendering, leaving out the details concerning where all the pipes, conduit, ventilation shafts and so forth need to run (traditional blueprints are also difficult to read if one includes all the little details). However, to be honest with you, I do not think that is a good solution in most cases -- it's just been the usual solution at most of the places where I've worked.What the "novice inspector" (typically a Business Analyst in the finance world) really wants to know is: "Will this software actually do what I intend for it to do?". Thus, to me, a better approach is to be able to provide the "novice inspector" with tests that he can run himself, with his own input data that are written in a language that he can quickly learn to read. I've used two frameworks that provide such functionality: Cucumber ( http://cukes.info/ ) and FitNesse ( http://fitnesse.org/ ). (There are others -- these are just the two I've used.) At one investment bank, we did not use either of these frameworks but provided similar functionality with a framework of our own, so I'll use that project as an illustration. It worked as follows: I realized that their Business Analysts preferred to communicate information in the form of spreadsheets, so I asked them to express their requirements as spreadsheets. Their Business Analysts were excited at the idea, so they outdid themselves and created huge spreadsheets with expected inputs and outputs, along with expected performance metrics (speed, load and so forth), and we wrote a test harness that those BAs could use to suck in the data from the spreadsheets and exercise the system we were writing. That was one of the first things we did on the project, which means that, initially, all the tests failed. As we added more features, more and more of the tests passed (and, at the same time, the Business Analysts were busy adding more data to the spreadsheets, trying to break our system -- they weren't being mean, we asked them to do that). By the end of the project, we delivered software that the "novice inspectors" knew was *exactly* what they wanted. In a sense, the spreadsheets and our test harness (which they had their in-house software engineers review carefully!) were the "novice inspector level blueprints". Not all software can be developed in *exactly* that way -- that system happened to have very well-defined interfaces. However, in my experience, most software can be developed in an similar manner, with "novice inspector level blueprints" testing system performance and functionality.

QuoteAt some level, physical engineering disciplines have it easy because there's a one-to-one congruency between the blueprint drawing and the final object. Even a child can tell whether a blueprint (e.g., of a triangular peg) and an object (e.g., a round peg) do or don't match.. I'm not sure that software has any such analog of a design document that can be easily compared to the final manufactured object by a novice inspector.The design blueprint is in the programmer's head.

QuoteOriginally posted by: CuchulainnQuoteAt some level, physical engineering disciplines have it easy because there's a one-to-one congruency between the blueprint drawing and the final object. Even a child can tell whether a blueprint (e.g., of a triangular peg) and an object (e.g., a round peg) do or don't match.. I'm not sure that software has any such analog of a design document that can be easily compared to the final manufactured object by a novice inspector.The design blueprint is in the programmer's head.That seems like a very bad idea. In physical engineering contexts, the blueprint is a major communication tool and often requires explicit approvals from multiple functions BEFORE the blueprint is ever used. Admittedly, the cost of machining metal exceeds the cost of hitting the compile and run button, so there's incentive to get things right at the blueprint stage, first.Of course, that might be another difference between physical and software engineering. In physical engineering, the edit-compile-run cycle is extremely expensive and drives a host of modeling activities to predict system performance from the blueprint (and sign-off on that performance) before making the physical product.

QuoteOriginally posted by: eDaveQuoteAt some level, physical engineering disciplines have it easy because there's a one-to-one congruency between the blueprint drawing and the final object. Even a child can tell whether a blueprint (e.g., of a triangular peg) and an object (e.g., a round peg) do or don't match.. I'm not sure that software has any such analog of a design document that can be easily compared to the final manufactured object by a novice inspector.That's interesting. I actually had thought of it almost the opposite way. One of the reasons I think that software engineers have it easy is because, given the blueprints (code), the final object is known because the computer (after a compilation or interpretation step) will execute the blueprints exactly as they appear. So to me, there is, in that sense, for software, a one-to-one correspondence between the blueprints (code) and the final object. True, you don't know ahead of time how the user or environment will interact with the software, but, for a given interaction, in a given state, you know (at least in principle) what the result will be. Consider physical engineering blueprints -- say, for example, an architect's blueprints for a house: Given the blueprints (a plan for a house), the final object is not known. The carpenters who build the house may or may not execute the blueprints exactly as they appear. In fact, in a typical situation, the carpenters will, here and there, intentionally do something that is different from the blueprints.So, while it might be easier for a novice inspector to read the architect's blueprints than it is for him to read the software engineer's blueprints (code), this inspector will have no idea if the house built from the architect's blueprints will actually be built according to the blueprints. On the other hand, he does know that software will be built according to the blueprints (code). Maybe. In the mechanical engineering and aeronautical engineering realms, the machinist is not free to change the design so it's much more like the use of a deterministic compiler. A part that does not adhere to the exact shape and dimensions of the blueprint is a rejected part and the machinist will lose their job if they make to many mistakes. Architecture is much looser and the as-built structure may vary from the blueprint design for consensual, unintentional, and financial reasons.Nor is the case in software isn't as deterministic as it seems, except in the cases of trivial code. If one uses more advanced features of a langauge, one might find discrepancies between how one thinks the feature works versus how one's compiler treats it. And any code that uses third party libraries is very likely to run into discrepancies between the documented design of the library and the as-built runtime behavior as well as face issues with different versions of a given library.QuoteOriginally posted by: eDaveThat still leaves us with the problem you brought up: How is a "novice inspector" going to review my software design?In my experience, the usual solution to the problem of "novice inspectors" needing to review software designs has always been to generate "higher level" documents from the blueprints (code). Once one has code, it is fairly straightforward to generate higher level documents, in much the same way that a computerized architecture system might generate a high-level "walk-through" rendering, leaving out the details concerning where all the pipes, conduit, ventilation shafts and so forth need to run (traditional blueprints are also difficult to read if one includes all the little details). However, to be honest with you, I do not think that is a good solution in most cases -- it's just been the usual solution at most of the places where I've worked.What the "novice inspector" (typically a Business Analyst in the finance world) really wants to know is: "Will this software actually do what I intend for it to do?". Thus, to me, a better approach is to be able to provide the "novice inspector" with tests that he can run himself, with his own input data that are written in a language that he can quickly learn to read. I've used two frameworks that provide such functionality: Cucumber ( http://cukes.info/ ) and FitNesse ( http://fitnesse.org/ ). (There are others -- these are just the two I've used.) At one investment bank, we did not use either of these frameworks but provided similar functionality with a framework of our own, so I'll use that project as an illustration. It worked as follows: I realized that their Business Analysts preferred to communicate information in the form of spreadsheets, so I asked them to express their requirements as spreadsheets. Their Business Analysts were excited at the idea, so they outdid themselves and created huge spreadsheets with expected inputs and outputs, along with expected performance metrics (speed, load and so forth), and we wrote a test harness that those BAs could use to suck in the data from the spreadsheets and exercise the system we were writing. That was one of the first things we did on the project, which means that, initially, all the tests failed. As we added more features, more and more of the tests passed (and, at the same time, the Business Analysts were busy adding more data to the spreadsheets, trying to break our system -- they weren't being mean, we asked them to do that). By the end of the project, we delivered software that the "novice inspectors" knew was *exactly* what they wanted. In a sense, the spreadsheets and our test harness (which they had their in-house software engineers review carefully!) were the "novice inspector level blueprints". Not all software can be developed in *exactly* that way -- that system happened to have very well-defined interfaces. However, in my experience, most software can be developed in an similar manner, with "novice inspector level blueprints" testing system performance and functionality.That's a very clever solution! The customer creates the prototype with whatever tool they like best and then the programmer translates it into an efficient code that adheres to the prototype's pattern of behaviour whilst also achieving performance requirements unattainable with the prototyping tool. Nice!But the real key isn't the "tests" because that seems to imply the programmers are monkeys at a keyboard banging out random code until the code passes the test. The missing piece is some common, industry-standard way for the customer/analyst/designer to define "intended behaviour" and a common industry-standard way for a programmer to propose a solution (a design document) that a non-programmer customer can review. Code doesn't feel like that design document -- it's too close to the programming-side and too far from the customer/intended behavior side.

QuoteThat's a very clever solution! The customer creates the prototype with whatever tool they like best and then the programmer translates it into an efficient code that adheres to the prototype's pattern of behaviour whilst also achieving performance requirements unattainable with the prototyping tool. Nice!Bad solution in general, unless the 'user' is a domain expert with intimate knowledge of core processes.This is a relatibely new phenomenon:a. Users with only basic programming skills.b. ITers without domain skills.(even the the term "IT" has no meaning). ExampleUser produce screen shots of the GUI dialog boxes that the develop subsequently implements.

QuoteOriginally posted by: CuchulainnUser produce screen shots of the GUI dialog boxes that the develop subsequently implements.This is ideal when the programmer is talented, and will never say "I can't do that." Typically involves a sophisticated user, who is capable of envisioning novel tool that he wants, where what he wants is valuable enough to pay for a custom solution. More common scenario is both user and programmer start with some existing application. User says I want something like this, except it just needs to do this one thing, programmer modifies open source to do what he wants.

QuoteOriginally posted by: farmerQuoteOriginally posted by: CuchulainnUser produce screen shots of the GUI dialog boxes that the develop subsequently implements.This is ideal when the programmer is talented, and will never say "I can't do that." Typically involves a sophisticated user, who is capable of envisioning novel tool that he wants, where what he wants is valuable enough to pay for a custom solution. More common scenario is both user and programmer start with some existing application. User says I want something like this, except it just needs to do this one thing, programmer modifies open source to do what he wants.Indeed.IMO this is the perfect relationship between two parties. When one or more preconditions is not satisfied then the project can run into difficulties. The better the relationship the greater the chances for getting the project in on time.I believe in 'stealing shamelesly' (legally) by using open source as this keeps the price down. One challenge is persuading conservative customers to adopt a better solution that has not yet reached critical mass in your domain. Then we get into the area of compliance/conformance and other non-technical 'missionary' work. Few (6) years ago I trained a COBOL programmer in C. Why not C++? Because it was too young a language. They wanted to wait a few years. Having an existing application (that gives the correct answers) is an ideal basis for the next revision of the software. For example, an application in C++ that must be ported to C# (for whatever reason). These projects are easy to estimate and to schedule. And risks can be quantified. For me, the 'meshuggah case' is when an 'unknowable unknown' (not discovered during project estimation) becomes explicit. Then you feel like the face in Munsch's famous painting..

One weakness of programming lanaguages and using them as a communication mechanism: the inability of programmers of large systems (in general) to express their intent in a concise, precise and checkable form, i.e. before they spend weeks on costly prototypes.