[cryptoz]

> It is 2012 not 1992

On the other hand, think of what you could accomplish with a weekend of work in 1992 and compare that to 2012. Our abilities as developers/designers/etc are vastly improved due to improved infrastructure, tools, communications, resources, etc.

You could build a distributed photo hosting and viewing application back in 1992. But you'd probably be writing it in C++ and it might take you a long time to get something that even works, much less looks reasonably okay and attracts an audience.

Now in 2012, you could hack that together in a weekend. To make it a real project may take a few weeks or months, of course, but the pace at which we can build things is indeed speeding up.

[mechanical_fish]

The problem is that once we make 80% of the process vastly more efficient, all it does is throw a spotlight on the remaining 20%. (This is the unheralded dark side of the Pareto principle. ;) Not everything about building an app gets more efficient with time.

You can now throw together a photo-hosting and viewing application in a couple of days. But that doesn't necessarily yield a site that runs itself. Teaching the customer to use the code still takes about the same amount of time. Editing the theme over and over again, iterating a design cycle that incorporates emails and meetings between you and the customer and the designer, still takes about the same amount of time. The process of moderating the uploaded photos to screen out the spam and porn still takes about the same amount of time. Usability testing still takes the same amount of time.

(And even in the enlightened year of 2012 there are still standard things that all sites could use, like proper reverse-proxy caching and solid backups, that over half the Wordpress blogs on earth seem to be lacking. Apparently we're not even done automating the things that could be automated.)

The other problem is that if the customer steps off the well-worn path they will fall into a very deep pit lined with invoices. If Wordpress does it out of the box, it's cheap. If Wordpress almost does it out of the box but it requires even the smallest amount of custom coding, it's expensive. And knowing what things are expensive and what are standard requires skills that customers don't have, so they have to pay a programmer to advise them, and that is itself inefficient and expensive...

[Tossrock]

> The problem is that once we make 80% of the process vastly more efficient, all it does is throw a spotlight on the remaining 20%. (This is the unheralded dark side of the Pareto principle.

I think this might be better referred to as the well-known outcome of Amdahl's Law: http://en.wikipedia.org/wiki/Amdahls_law

[mechanical_fish]

Agreed, but if I'm going to jokingly but inaccurately name-check a principle involving the number "80%" I might as well pick on poor Pareto. He's used to it by now. ;)

[arctangent]

These days we can certainly build more, faster. But I get the impression that customer expectations are rising at a much faster pace.

[trotsky]

nntp://alt.pics.pets

There is 1992's distributed photo sharing app, built in ~5 minutes without any c++ and you had the whole rest of the weekend to get into flame wars about how ugly someone's cat was.

Sure you can get a lot more done now with advanced tools and infrastructure, but really expectations and requirements have grown much faster. You could definitely launch a median web or win32 app in '94 faster than you can now.

[tewks]

Time to prototype has definitely gotten cheaper.

C is still necessary for a lot of people at scale.

[tomjen3]

I doubt that -- there aren't that many programmers writing lowlevel OS or database code and most everybody else use something more productive.

[georgieporgie]

think of what you could accomplish with a weekend of work in 1992 and compare that to 2012

In 1992 I could bang out some really effective CUI applications in no time at all. People really hadn't transitioned to Windows at that point. Now, I have to write a web app, or a mobile app, and it takes hours upon hours to learn the ins and outs of each new API, weeks to figure out how to customize the flashy UI to what the client wants, etc. So, yeah, programmer tools have gotten vastly better, but expectations and complexity have risen faster.

[wallflower]

> So, yeah, programmer tools have gotten vastly better, but expectations and complexity have risen faster.

I am going to roll this into my conversations with non-tech friends. It is like the magic time saving appliances of the fifties...