Re: [xml-dev] RE: XML As Fall Guy
Hi Mike,
Creativity is the word, and there is a book on this subject 'Software Creativity' by Robert Glass, that is a compendium of articles actually. All that you say I agree with fully, another reason metaphors in software are problematic. My interest is mainly why large projects fail and why tendering doesn't work that well for software. I suggest when it does work, that the cost is far greater than is necessary, at least double in my experience, in order to guarantee a result, irrespective of it being a good result. There is a tender for a 'health information exchange' locally at the moment, a perfect thing for open-source in my view, complex yes but essentially commodity. I know that this will not be the result.
On Thu, Dec 5, 2013 at 12:35 AM, Michael Sokolov <[email protected]> wrote:
On 12/3/2013 10:20 PM, Stephen Cameron wrote:I think this gets at something important: the creative film-making analogy seems a reasonably good fit for a word processor, or web shop: human-facing software. I don't think it works as well for building a database, web server, file system, compiler, or operating system, even though humans do use those.
Going back to my film analogy, you start with a script usually produced by one person, is that the film design? One that the director, actor and camera-persons etc (as manufacturers) can follow to a predictable result, obviously not! That creative team has to turn the script 'vision' into a product that works for the human audience.
[We might be talking about different kinds of software it occurs to me, I am mainly talking of software that provides information to humans, where meaning becomes such a big issue, not that which controls machines].
This observation suggests to me that the difficulty we have with analogies for software-making arises from software's protean qualities: software can be written to mimic almost any process or system. Thus different analogies are appropriate to different scenarios. If we discuss software that mimics human perception, like speech recognition systems, or other primarily numerical software, then the building process becomes an exercise in scientific research, rather than a creative endeavor, and doesn't have much to do with building construction in any case.
It might be instructive to identify an appropriate metaphor for a particular software discipline or field of application, rather than trying to find a single correct metaphor for all software practice.
-Mike