Developing software in "Internet time".

When it comes to software development, something changed in the last 15 years or so. Sadly, we have not figured out the way to write software without bugs, neither have we come up with a way that allows non-programmers to put applications together. However, what has definitely changed is the time our programmers are allowed to sit on a project before they release the code. Let's put it this way: code has become a big business, which means that the time that can be dedicated to the development of a particular product has now shrunk significantly, since there is a need to monetize it as soon as possible. And what changed all that? It was the Internet and, above all, Netscape. Michael Toy, ex-Netscape employee, has an obvious bias for developing software in what has become to be known as Internet time:

"... I frankly admit that I am heavily biased toward: Let's ship something and put it in people's hands and learn from it quickly. That's way more fun, way more interesting, and, I think, a much better way to do things than to be sure that what we're doing is going to last for ten or fifteen years. It looks like Chandler is trying to be very architecturally sound and to be almost infinitely willing to delay the appearance of the thing in order to have good architecture. It's Mitch's money, so he can make that trade-off any way he wants. And it could be that that willingness to go slow is going to pay off hugely in the future. But it's really hard for someone who wants to ship software next week."

(Rosenberg: p. 171)

It's the very same approach taken by open source development: release quick and release often, then make changes depending on the users' feedback. This is quite far from the original intent to reach perfection that was shared by pretty much every original software engineer. Back then, the aspiration was to "write software like we build bridges". I'd say the overall attitude has changed now. We don't think we can build the perfect program anymore. We prefer to think of it all as a process, not an end product. Even better, it is a process that never ends. We put together a prototype and release it out there. Users give it a try and provide some feedback —some of them may even provide code too! Then, we take that and build upon the original prototype. In other words, software development is less software engineering —building a definite product from the well defined plans— than a craft or an art always trying to perfect itself by the use of a set of so called good practices. This is the hige shift in mentality brought about in the field by Internet time.