Good Software Takes 10 Years?

webword writes: "Joel Spolsky is running an editorial where he claims that writing really good software takes ten years. (Yes, TEN years.) He explains several mistakes that are made by companies that don't understand his ten year principle. The mistakes are backed up with some interesting industry examples, so it isn't just vapor. Unfortunately, he doesn't mention any OSS/FS examples, but I'm sure we can handle that. I am mostly skeptical of his idea because I'm not sure how he thinks a young software company could possibly survive without building really good software in much less time. Spolsky mentions that new companies need to strictly control their cost structures, and that will save them, but that doesn't seem like enough to me."

Comments

Thank God... finally a programmer who understands.

[Anonymous Coward]

It's all about job security folks, why build an app in 3 months when you could spend some quality time reading slashdot and drag the project on for ten years.

Those old hippies were smart.

Re:do you even know

[joss]

nearly...

Marc Andresson was an intern at NCSA. His maths wasn't good enough for him to do what he was hired for, but he did know motif pretty good, so his superior Ping Foo asked him to write a GUI for www. This proved to be a good idea. Then Jim Clarke (founder of SGI) thought it would be a good idea to commercialise the idea, and hired the more commerically minded people from NCSA (not the same as the smartest, for instance - Ping whose idea the project was, and who made some of the smarter design decisions (eg single click to follow link), never joined).

Netscape was the browser tail wagging the internet dog for a while, but they declared MS history too early. The VC money they got from being declared the next MS enabled them to hire 1000s of developers very quickly. This was profoundly stupid, because having 1000 mediocre developers is far worse than having 10 decent ones. These people wrote 100s of 1000s of lines of shitty code. This code was then released to the mozilla effort, and left it with no fucking chance. Writing a browser isn't *that* tough, but if you start with a massive shitty code base, you can lose sight of that.

You don't need to release good software to survive

[Christopher Craig]

You can easily survive 10 years without releasing "really good software". How many people bought Mechwarrior Mercenaries? Win95? How many installations of sendmail are out there? bind 8? I think we would all agree that the likelyhood of encountering a bug in these is pretty darned high, and yet people bought and installed them anyway.

MS IE

[larien]

I will give the Internet Explorer team credit. With IE versions 3.0 and 4.0 they probably created software about ten times faster than the industry norm. This had nothing to do with the Internet and everything to do with the fact that they had a fantastic, war-hardened team that benefited from 15 years of collective experience creating commercial software at Microsoft.

Personally, I'd put a lot of it down to them nicking the Mosaic source and using it. That effectively makes the time of development something more like 6 or 7 years rather than the 2 or 3 MS worked on it.

Also, I'd agree with others who have posted that this counts for things like OS's, DBMS's and the like. To create a simple application (eg, a text editor) should take less time.
--

I disagree. It takes good programmers

[Katravax]

If programmers wrote solid code and tested it thoroughly, it would not take ten years to produce truly good software. I see more unchecked parameters, non-tested failure conditions, and badly designed function interfaces now in the work of the average programmer than ever before. I'm not sure who or what to blame for the problem (dare I say comp-sci curricula?), but I suspect part of it lies with the fact that "safe" languages are the first most programmers gain mastery on.

Hey Taco...

[bachelor3]

Hang on to that HP3300C scanner...you're gonna get a really good linux driver for it in 2011.

Quake

[mhelie]

A lot of games have been in development for a very long time and are still being developped. Quake, for example, is 5 years old and at least three upcoming games I'm aware of (SoF 2, Wolfenstein, Medal of Honor) are using it. Unreal has also been in development for years.

Just because it changes on the surface doesn't mean the whole program gets scrapped and everyone starts over. Unless we encounter a serious technological bottleneck in our current engines, it is quite likely they will still be in use in another five years.

-------------------------

No way...

[Pedrito]

I've been apart of software projects that produced "Good" software. Really good software, in my opinion. Really good, large systems that were reliable and the users loved them. One took roughly 3 years to be ready for market and had another 2 years of additional development.

Another is one that we're nearing completion on. It has taken 1 year for four developers, and it's a large distributed system. It's very stable and it's good software. We've also taken on the idea of "plugins" and exposed a great deal of our system's internal data and functionality so that we can add almost all of our new features via the "plugins" and not have to worry about mucking with the base system and messing it up.

Now, as my old boss used to say: "We're not sending rockets to Pluto," but these are fairly large complex system.

The first was a multi-user engineering system for developping cell phone networks (base station locations, traffic analysis, propagation prediction, interference prediction, etc...) The second is an enterprise wide tracking system, used to track everything from bugs in the software itself, to evidence in police stations, to prisoners in prisons, to assets for a company.

So, I don't really buy into the 10 year thing. Not to mention the speed of technology changes, hell, you can't design for what's going to be there 10 years from now. Who knows what's going to be on your desktop?

Wicked problem

[Atom Tan]

Obviously, 10 years as a blanket maturation time for all software is over-the-top. But Spolsky does make some good points about software development. His main points can be summarized in the statement that creation of new, non-trivial software is a "wicked problem"--it requires constructing an incomplete or unsatisfactory solution to fully characterize the problem in the first place. A deep understanding of software design as a wicked problem will make you a better (and less frustrated) developer. For example:

• Requirements will always fluctuate throughout the development cycle, because users cannot entirely formulate what they want until they have seen something close. For the same reason, requirements can never be fully formalized--the more explicitly complex behavior is described, the more likely it is not exactly what the user wants.
• It is nearly impossible to get a complex design right the first time, even if you are among the very best. Design and build functionality slowly and incrementally, and expect to revise aspects of the design and code you didn't anticipate revisiting.
• All non-trivial software has defects--you should accept this and spend time and effort developing an effective QA process, rather than treating QA as an afterthought or feeling guilty that your software has bugs. The development process lasts months, but the QA process lasts for the lifetime of the software. Concentrate on making the software better, not just fixing the bug at hand.

These are just a few points, acceptance of which will lead to more effective development. A big barrier to acceptance of the real difficulty of software is that we spent our formative years developing trivial, batch-oriented programs that our professors could run easily and grade objectively. With these programs, the requirements were known upfront (any ambiguities having been flushed out by repetition of the assignment), the program was known to be doable by most developers in the alloted time, and it could be completed bug-free. None of those things is certain in the real world. Yet we treat complex software as if it can be done this way. It doesn't work--"Zaro Boogs", anyone?

Depends on the project..

[onion2k]

I'd agree in prinicle. To write Notes, or an OS, or a DBMS, certainly, 10 years is probably a fair amount of time to get something of reasonable quality. But..

Not all software has even close to thelifespan of the big applications this guy is talking about. Most user applications, games, web technologies, they are all projects that get used for a few years and then get replaced. To develop a single game for 10 years would be madness. The amount of time a project has is usually linearly related to the lifespan of the outcome. If you're writing soemthing thats going to be used in 20 years time, then its probably not an afternoons work.

Re:Depends on the project..

[update()]

Not all software has even close to thelifespan of the big applications this guy is talking about. Most user applications, games, web technologies, they are all projects that get used for a few years and then get replaced.

I agree about games, with the exception of low-tech stuff like Angband and other Rogue-likes. I also agree about simple utilities. (That's why I don't care whether Miguel and Ximian decide to throw their energies into chasing .NET -- the stuff I care about in Gnome, like grip and xchat, is only going to get slower and buggier if they ever really get Bonobo in place.)

But user applications like office suite components, financial applications, things like that definitely need time to mature. It took Word and Excel years to go from their original Mac-only incarnations to their usability peaks (Mac Word 5.1 and Excel 6.0, IMHO). And web browsers are far more usable than they were five years ago.

While I'm here, responding to some things in the article:

Mistake number 2. the Overhype syndrome. When you release 1.0, you might want to actually keep it kind of quiet.

A corollary of this -- don't crank up the hype before you've written anything! That way lies Eazel, Mozilla, Marimba and, I'm guessing, Mono.

Mistake number 5. The "We'll Ship It When It's Ready" syndrome. Which reminds me. What the hell is going on with Mozilla? I made fun of them more than a year ago because three years had passed and the damn thing was still not out the door.

I made fun of them, too. Until it turned out that its function at AOL was to serve as a bargaining chip with Microsoft. It did its job. And I don't think you can fault them for not releasing those horrific 0.9 versions as 1.0. You can fault them for taking so long to make it usable.

Unsettling MOTD at my ISP.

Re:Bad, Good and great software

[hillct]

The submitter of this article states:

I'm sure we can handle that. I am mostly skeptical of his idea because I'm not sure how he thinks a young software company could possibly survive without building really good software in much less time

Perhaps it could be said that the customer expectations in the software industry have effectively closed the market to new companies in some areas.

Will there ever be a new commercially viable operating system (not saing Linux is bad, but just that it's market share is far too low to consider it at this point)? Can suchan effort exist if the company producing it needs seed capital for 10 years of operation before a quality product can be produced?

This seems actually to be a great opening for Open Source. OSS has the advantage of not requiring large capital outlays to continue development. Look at the number of OSS projects started in the past 5 years, and at the number of corporate software startups from the past 5 years. How many of the corporate software startups are still around? How many OSS projects are still around?

I recall a statistic someware that only 2% of companies ever really succeed, beyond 3 years. I wonder whatr that percentage is for OSS projects...

Based on the above comment, it seems to me that the only major competition in large scale software such as Operating Ststems, Enterprise quality databases and Perhaps Wordprocessor software will come from OSS, which is the only development model that could survive for the decvade nessecery for the products to reach maturity.

The alternative is to say that the only major software companies that will ever exist have already been established and that the bariers to entry into these markets are too high for any new startup. This is not something I would ever want to have to admit.

--CTH

--

Good Software takes FOREVER!

[Codeala]

I think a software is only good iff it takes forever. As software *approach* perfection, changes are made less often. New features are still being added, but they are few and far in between. Eg old warhorse like tar now has support for .bz2 files (tar -zI). It is impossible to say something is perfect and cannot be improved anymore. Anyone remember that quote about "all the inventions had already been invented"?

Of course this probably don't apply to the commercial environment (which is what the article is aimed at I think). Imagine starting a business selling tar: buy tarXP because... okay lets go to a subscription model ;-)

====

Not 10 years for the first release...

[n76lima]

I work in the medical practice management business. A group of Docs that I consult with have their own PM app suite that they had written in house. Its 14 years old, and has gone through 2 major re-writes. It ddn't take 10 years to produce good workable software, but it continues to take development to refine it and add features that the staff need to transition to an office model that uses less paper. It started as a DOS program and evolved into several DOS sessions that could be task switched under Windows 3.1, then 95. Now the current version is all Windows (on the desktop, we run extensive Linux support on all the servers). They have had a full time programmer on staff for 14 years with no end in sight. The current thrust is to make the medical records available to the Docs on the web through a browser interface. The cost to develop it has all been paid by 1 clinic, and I estimate that they have ~$1 million tied up in the coding over the life of the project.