OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] RE: XML As Fall Guy

Hi Thomas,

So how was that different from what we've been saying for software? Except of course for the complexity, but I mean in terms of the estimation, flow, and iteration of the program.

Firstly, thanks for sticking to your guns! I am being dogged about this as I see it a *such* an important issue. In my view mega-millions of dollars of public money are being spent in this area, which with a changed perspective might produce a much greater benefit. That tendering for software is flawed, I am looking for a clear explanation of why.

At a fundamental level there is no difference, you have creative people, with a background technical training and experience, doing designs.

In the case of software that is the end of it, job done. In the case of hardware the design is handed to the manufacturer and the product made. If both the designer and the manufacturer know their stuff, happy ending, satisfied product user. If not, then 'back to the drawing board'.

In the case of software there is no equivalent to the manufacturer, there is only the designer according to Reeves. If a job is too big for a single designer (forget programmer), you have a problem. The standard thinking has been to sub-divide into roles for 'architecture' and 'implementation'. This is essentially a divide-and-conquer strategy, which is good, but my main problem is that the terminology leads to mistaken thinking, that its going to be as reliable as the designer and manufacturer subdividision of labour usually is.

So you don't really have the hand-over from 'architecture' to 'implementation' with software as its all design, instead you have constant feedback between the two groups of designers (broad and specific). Now if you try to get domain experts involved as well, so that what is designed is actually fit-for-purpose, there is even more communication and feedback involved.

[I think this is why software monopolies have been so common actually, once you come to dominate the relationship with the user is so close it becomes a barrier to entry for anyone else, the feedback between designer and user becomes a virtuous circle that no other competitor can break. It takes a new platform to allow new players to dominate, such as the web (Google) and mobile (Apple)].

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].

Also, like software, once designed a film can be distributed in digital form very, very cheaply, its just copying it onto media for distribution.

For me this is what is so fascinating about the web and open-source, that essentially the creative process around design of software becomes a continuous process of refinement. There are so many creative people who want to be involved (the designers are like a collective intelligence), you don't have to set up a factory to 'go into production', and the 'distribution costs' are negligible. All this is largely being ignored by governments because they are stuck in the old, pre-web, 'procurement' paradigm.

I forecast a time when there will be a professional class that provides a service based on their knowledge about open-source software systems and how to make effective use of them. That software will come to be seen as a collective heritage like other written works, and legal systems, as parts of human culture. [Which leads on to the software patents debate...].

So, software is different.


On Wed, Dec 4, 2013 at 12:37 PM, Thomas Passin <list1@tompassin.net> wrote:
On 12/3/2013 6:53 PM, Stephen Cameron wrote:
All this discussion of logistics and quality control, engines, brakes
etc. misses the point that I've tried to make that *software is
different*, drawing analogies is actually dangerous (but something done
all the time in our minds). I believe that you cannot separate the
design from the production of software in any meaningful way.

This isn't settled for me.  Sometimes I think that, sometimes I don't. Right now I'm thinking back to a time when I worked at designing hardware - radiation detectors.  Our sales people had gotten a job to build a replacement for another company's unusual design, and only four units at that.  It was very difficult to design, especially since the original used certain items that would have been hard to impossible for us to get.  Also, the unit was very long and needed unusual internal support structures.

I designed it and we were about to start cutting metal, when after a review I realized that it wouldn't work - it could not be assembled.  We took a month and completely redesigned the internals.

Because of the difficulty and novelty of the design, when I had estimated the cost to build, I assumed that we would have to do one complete rework, and that a rework would cost almost as much as building another.  I moved on to another job before this contract was completed, but I later found out that in fact the first unit had to be completely rebuilt.  The manufacturing cost came in very close to what I had estimated.

So how was that different from what we've been saying for software? Except of course for the complexity, but I mean in terms of the estimation, flow, and iteration of the program.

This example illustrates why I'm not so sure that software development is really fundamentally different from hardware development.  I'm inclined to think that the most significant things that make software hard to develop (and manage the development of) are 1) the complexity, and 2) the fact that a lot more creativity is needed than managers want to credit.

The matter of scale is another matter.  I see many people getting mixed up about small vs large scale.  Large scale for any kind of project is difficult to manage.  Small scale, much of the information can be held in the heads of one or a few people.  Iterations are quick and easy. Communication is easy, or at least easier.  It's feasible for one or all participants to understand the problem domain and to grasp what the system has to do.  For large systems, it's quite otherwise.

If you don't know how to manage and develop a small software project, then surely you're not going to be able to manage a large software project well!  The reverse isn't the case, though, sad to say.


XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS