Slashdot Mirror

← Back to Stories (view on slashdot.org)

Good Software Takes 10 Years?

Posted by michael on from the we-will-sell-no-upgrades-before-their-time dept.

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."

6 of 250 comments (clear)

  1. Thank God... finally a programmer who understands. by Anonymous Coward · · Score: 5

    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.

  2. Hey Taco... by bachelor3 · · Score: 5

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

  3. No way... by Pedrito · · Score: 5

    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?

  4. Wicked problem by Atom+Tan · · Score: 5
    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?
  5. Depends on the project.. by onion2k · · Score: 5

    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.

    --
    http://twitter.com/onion2k
  6. Not 10 years for the first release... by n76lima · · Score: 5

    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.