Lost me sorry
I was referring to notion that tenders are incapable of producing a good
result with software 'procurement'. An iterative process allowing for
refinement of a solution (prototyping, code-as-design), that allows
developers and domain experts to learn from each other, is the antithesis
of 'procurement'.
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. Yes, TDD is quality control
but aren't the tests software that have to be designed!
Steve
On Wed, Dec 4, 2013 at 1:26 AM, <cbullard@hiwaay.net> wrote:
"Yet there is no mention of questioning the validity of the very notion of
'procurement' itself"
Don't confuse artifacts and processes that meet requirements for cost
transactions with software design. The inability of software analysts to
grasp the fundamentals of logistics is one of the drivers for the churn in
software tools and products.
The essence of waterfall is not seeing over the wall. Programmers in
agile environments make the mistake of thinking they are the center of the
transactions. They are not. They are an engine, not a steering wheel or a
brake.
len
_______________________________________________________________________
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
