Re: [xml-dev] Re: XML As Fall Guy

[Ian Graham <ian.graham@utoronto.ca>]

Worth having a look at http://scribblethink.org/Work/Softestim/kcsest.pdf,   which attempts to demonstrate:

"Algorithmic (KCS) complexity results can be interpreted as indicating some limits to software estimation. While these limits are abstract they nevertheless contradict enthusiastic claims occasionally made by commercial software estimation advocates. Specifically, if it is accepted that algorithmic complexity is an appropriate definition of the complexity of a programming project, then claims of purely objective estimation of project complexity, development time, and programmer productivity are necessarily incorrect."

Which effectively means it's impossible to predict cost / timelines for sufficiently complex problems, without actually doing the problem.  A bit of a 'duuh' maybe for those here, but it's still nice to have this backed up by a fancy paper with a cool mathematical proof.

Ian

On 12/1/2013, 4:13 AM, Ihe Onwuka wrote:

On Sat, Nov 30, 2013 at 3:11 PM, Thomas Passin <list1@tompassin.net> wrote:

The problem of writing requirements up front is that one often can't know all the important aspects of the problem until one gets well into trying to solve it.  Same with quoting a project - early on, you can't quote with precision unless the job is very similar to others you have done.  But a contractor has to know what it's bidding on in good detail, so you can't just leave lots of details until later.

The contractors can't bid intelligently because they usually don't have the core competencies (and often don't even know what they are) and will be planning to outsource them. A prime reason they are brought and paid a premium is so that the client has a central focal point for outsourcing blame.

The odds that they stumble upon the right technologies and the right people are extremely slim , few companies are intellectually agile enough to possess that expertise in house. That model of a company with specialist consultancy practices (applicable in most other professions) has largely died out in IT and been replaced by outsourcers that offer primarily project management skills that reckon they can throw together a team of people to meet a need. Unless the client already largely knows the technological space they are dealing with there are way too many things that can and will go wrong. I can only assume it's done because the front end of an application can be a very effective camouflage for monstrosity and the expectations on the contractor are so low.

Again if you look to other professions this is not how they do things.

-- 
Ian Graham // <http://www.iangraham.org>