I was thinking of something like listing out the core data (and any 'significant' attributes), the important functionality and the primary interaction with the users (user cases, sortof). Something like:

You manipulate free-flowing text with a text-editor. There is some navigation to find a 'document', then the create/modify/delete mechanics for letters/words/paragraphs. Usually a view presentations, printing, etc, and a few summaries (words, paragraphs), and a few traversals (spelling, grammar), etc.

The main user interact is a wide loop switching between navigation, commands and data-entry.

Of course, the idea is to be as 'spartan' as possible in describing it, but provide enough details to make sure the output was acceptable (a relative thing).

 out of  found this valuable. Do you find this valuable?    

"Because functions map (context, data) -> (result, side-effect), I believe that the software blueprint has to then include a complete listing of mappings are included in the system. Obviously, a more compact representation will provide some sort of invariant version for these mappings. The alternative would be permuting out every possible data and context value combination and their output, a listing much greater than the underlying source code."

I think I'm slightly off. Functions, and their arguments, take data, in a context and map it too a result and some side-effects. Neither the data nor the context need or care about the specifics of the function's arguments. Should be: function(context, arguments, data) -> (result, side-effect).

In this sense, there is a decomposition of software into function-sets and data-structures. If you list out all of the data-structures and function-sets in gory detail, then a computer should be able to translate that into steps for execution.

 out of  found this valuable. Do you find this valuable?    

My guess would be to just let the project go where it is interesting; we have a lot of history that could me mined at some point (someday "software historians" might be a real occupation :-)

At some level text and graphics are different but similar ways to represent information, text is just a more formal structured set of 'glyphs' that together have complex meanings. Graphical representations always pack more 'punch', I think. They can convey so much more, in a smaller format. Text, on the other hand is far easier to work with. You can mine it, and use tools to ensure the formatting is correct or automatically summarize it.

In some strange sense, blueprints, to me are simplified representations of the thing you want to build. That 'information' should be equally usable in either graphical form or text form. We could for instance take a construction blueprint and boil it down into some XML. That might not make it nearly as useful on the construction site, but it would allow the plans for be searched and easily edited. Both have their moments.

Way back, I remember using some software for creating ER diagrams. You could import SQL, and it would draw the diagram, or you could work on the diagram and export SQL. When I was doing large-scale changes, I found it easier to export the SQL and change it in an editor. For small changes, the graphical version was best. If I wanted someone else to proof read it, I gave them the graphical version. Having both was great.

1  out of 1 found this valuable. Do you find this valuable? Do you?