Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Formalism and complexity
 On Mon, 2004-01-05 at 14:57, Simon St.Laurent wrote: > igraham@i... (Ian Graham) writes: > >This reminds me of the "limits to software estimation"[1] article, > >which relates the software estimation problem to the algorithmic > >complexity of the problem, particularly in the large problem > >size/complexity limit [I thought this was discussed on this list > >before, but can't find any reference to it]. > > > >Funny how everything seems to end up at complexity, one way or another > >;-) > > >From my perspective, much of the problem comes from the way we try to > design software: as coherent systems. > > Most complex human systems originated organically; no one designed > Paris. Even in the most planned of communities, it's unusual for the > color of the bathroom paint to be strictly specified. > > I'd hoped that XML's extreme openness would be an opportunity for this > kind of openness to appear in the computing world, a chance for > developers to accept the chaos that often produces fine results in the > real world, even in the business world. > > For the most part, though, I continue to hear "XML is an okay syntax, > but still we must all agree on semantics precisely for anything to > work", the same dispiriting story that's kept complexity as a barrier to > sophisticated computing. > > Software developers are happy to design bathrooms and buildings for > other people, but let them choose the paint color? Their preferred > lighting? Perhaps most important, the pathways in and out? > > Nope. We have "design patterns" all over the place, but no notion of > the common pattern "ENTRANCE TRANSITION". No wonder we have such > trouble estimating and completing work. this is part of the stuff of extreme programming - setting up systems that can grow organically - that's what i'm trying to do and that's why i think xml is part of the solution if you recast your economics you get a much better solution.... traditionally we try to get a pre-implementation cost/benefit and then put walls around what we are doing so that the costs are contained - after all we already know the benefits/cost savings - or do we? most of my systems involve hundreds of tables, thousands of programs, and who knows how many business rules (all explicitly stated in the data dictionary by the way). but you can't plan these systems very well because as already noted, the users don't even know the potential for the system in advance. perhaps more importantly, the development of the system and interaction between the programmers and users opens up new ideas and possibilities for both groups. fixed specs pretty much destroys that opportunity. so if we go back to one of the more intriguing results of number theory - probability of hitting a rational number when picking a random spot on the number line - 0. i tend to regard user specs a bit like rational numbers - easy to see, but there's an infinite number of possibilities unexplored between each user's idea of what the system should be. my economics is simple - the cost of implementation should never be more than the anticipated 6 month saving - ie you're ahead after 12 months. arbitrary but it's simple and satisfying for the customers. then it doesn't matter how big or how long it takes to put a system in place because the savings keep accumulating. the simpler, more primitive parts of xml are excellent in this scenario. the more complex parts start to break down the savings because of implementation costs and times. rick 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
