A 14-year-old could build 1998's Google using her Dad's credit card!
Technology speeds everything up - more so in some areas than in others. While it's easy to see that erecting a 15-story building in two days is faster than it's used to be done, it's harder to get a grip on the giant strides we're making in software construction. Nonetheless, software is probably the discipline with the most reliably accelerating productivity.
Just a few years ago software wasn't moving all that fast. In those days most programming time was spent on squeezing the maximum performance from CPU and memory and programmers like John Carmack achieved lasting fame for their knack for teasing just a little bit more performance out of machines. And a few years before that, as prog21 points out, even writing a working basic spellchecker was a major achievement. You simply didn't have the memory to store a list of words. Never mind building a really good spellchecker, you'd be busy with optimizing the base case.
But whenever hardware advanced, it only took a jiffy till programmers would again use up all that extra power. At that point in time, software's progress was held back by the (comparatively) slow-moving physical nature of hardware. However computer networks were able to free software from the shackles of hardware: If you built your software right, you could just add more servers as you needed them, instead of relying on manufacturers to provide faster and faster hardware.
Google was among the pioneers of networked architecture and built its service using arrays of cheap commodity hardware from the start. But it wasn't until 2006, when Amazon introduced the Elastic Compute Cloud (EC2), that the chains of physicality were finally broken for everyone. Now you could add and remove machines from software as needed. This development opened up a whole new way of thinking about software to every programmer on the planet.
Three years later, in 2009 I proclaimed to a friend:
Today a fourteen year old could build 1998's Google using her dad's credit card!
To put that into perspective, there's three parts in play here: 1998, her dad's credit card, and the software engineering knowledge and tools required to build what Google built in 1998. Let's start with 1998: The internet was much smaller back then. By the end of 1998, Google had an index of about 60 million pages, and Larry Page's web crawler had been exploring the web since 1996. The total amount of data downloaded was probably in the ballpark of 200 gigabytes by the end of 1998. Storing 200GB of data on 33 bleeding edge 6GB hard drives at $370 a piece would have cost about $12,210 non-inflation-corrected at that time. That's without the hardware, electricity, nor bandwidth to actually operate machines to fetch and store the data. In 2009 you'd have gotten a 1000GB drive for $74.99 and could have run it from a single computer, while people regularly download more than 200GB a month on unlimited cable broadband.
So getting the data had become cheap enough for our hypothetical teen's dad's credit card. Crunching the numbers would require a few more resources, but 1998's internet was small enough to be crunched on EC2 with her parents's credit card. Serving the data and answering queries on a popular website without feeling sluggish would also require a few more servers. Let's assume 30 servers would handle the peak load for a start (Altavista was running off 20 multi-processor DEC 64-bit Alpha's in 1998). At not-the-cheapest-at-the-time $70 per server-month on Amazon, that would give us an estimated cost ceiling of $2100/month, with the expected cost being more along the lines of $500-$1000/month. Now I'm sure Dad wouldn't appreciate it, but for many people that's in the ballpark of what they pay for rent and thus affordable.
So theoretically speaking it could have been done in 2009. More than that, price-wise it probably could even have been done in 2006 without ever touching any hardware yourself. But of course money wouldn't have been the only difficulty for a hypothetical fourteen year old tryi