Software Blueprints

I'm talking about 'engineering' here, go somewhere else for ComputerScience. (Envious smirk.)

Item One: There is no software engineering, but, maybe, someday, there will be.

Say I'm designing a hypothetical piece of software (now there's a phrase for you: What a piece of SOFTWARE! (with disgust) Use it often, say it loudly!) that needs a certain kind of widget. If I were an engineer, I would be able to look up or compute the expected stresses this widget would experience in use, say, the largest number of bytes it would be expected to store at one time during the next 10 years. (Civil engineers work with 100 year storm maximums and stuff like that.) I would be able to look up data or formulae for different fully specified widgit implementations and choose the one (implementation) that satisfied some requirement. I should be able to choose a linked list implementation that uses is own memory arena and buckets so as to get a locality of reference figure that will guarantee the specified performance on the specified architechture. And all this without a line of code. THEN I'd be an ENGINEER! Until then I'm JustaProgrammer.

Instead we coders have maxims, like "start with the simplest algorithm", "don't reinvent the wheel", "it's O(log2 n)". I'm not bitter, just anxious.

Item 2: Has anyone else noticed, and is it true that software engineering is the only brand of engineering where the blueprints are the finished product?

Where I consider blueprints:

To have sufficient detail to actually build the finished product, not just requirements and diagrams * Are not the bridge you can cross, or cellphone you get billed for answering

Now, notice that I said 'software', not source code. The difference between source code and executable is the difference between the the words in a book and the sounds in the air when that book is read. (Or the picture in the mind of the reader, but let's not go there without a cross-compiler, OK?)

In software engineering, the blueprints are close to the finished product. OTOH, it's the same with books. What we're really getting at here is, if you think of the manufacturing paradigm, the software manufacturing shop is ridiculously fast and cheap, as are the raw materials (disk space). --RobMandeville

Item 3: We need a body of reference material to help us make design decisions based on concrete experience gained much as other disciplines have.

I'm not saying text books are insufficient, just not complete.

For example, as a start, does anybody know of or want to start a database of successfully completed software projects? It would help an architect or analyst say, "We need a module that does this and so. Other similar projects had so many programmers, took so long, had so many lines of code, was in this kind of language, etc. "

This is not entirely so they could say "Hey! Maybe we can buy their module!", but so that they could get a realistic cost in time and effort. It would be entirely anonymous (if desired) so even that big software company we both love and hate could participate without being embarrased. (Although they might skew the cumulative curves/ratios a little.)

Another needed source of data would be similar: maintenance statistics for the same projects above. It would answer the question, "Can we even afford to maintain this sucker if we do build it?!"

Obviously, it would also be nice to have commercial grade reference implementations of common data structures and algorithms (something somewhat, but not completely, unlike the STL) with supposed speed/size enhanced variants and statistics for different architectures. (A lot of this stuff is already available, but not collected into authoratative references.)

As I read somewhere else (cue the WikiGnomes) this kind of material was and is peer produced in other engineering realms, so I guess it's up to computer scientists, software engineers, programmers, and coders to get the ball rolling.

-- BobBockholt

Please place your references to published works with tables of hard numbers and exact formulae in this section.

Thanks.