The issue is the same as with code everywhere: unless you start from a position of discipline you can easily end up in trouble - code that was intended to be th

The issue is the same as with code everywhere: unless you start from a position of discipline you can easily end up in trouble - code that was intended to be throwaway ends up in production, code gets shared around and modified hence duplication and difficulty in maintenance.. I could go on. Suffice to say in my experience the majority of organisations that have a GIS requirement of any significance usually seek to control code tightly, and would rather spend money on a COTS solution that can be operated by a relatively cheap GIS analyst, rather than hiring in more expensive dev skills - the dev work can be performed by dedicated devs or contracted out as necessary. Similarly the demand for apps with a geospatial element has exploded and the last thing a GIS manager wants to do is to have heaps of custom code written for an app that may only be used for a month, for example. It's in this situation that wizard driven app creation is valuable, with perhaps minimal code for special requirements. I don't like it because you see deskilling of GIS analysts at one end, and deskilling of GIS devs at the other - but this seems to be an emerging trend. I'll certainly acknowledge though that the profusion of free tools and data are shaking things up, so I'd be happy to see it continue. ARC/INFO was command line, lest we forget.