Slashdot Mirror
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."
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.
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.
http://rareformnewmedia.com/
Uh, if you have a logical language that describes what your program is supposed to do, why not just compile it? It sounds like what you're doing is writing the same program twice in two different languages and comparing the output - you would be better off with a code generation tool.
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.
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.
--
The word "good" in the authors article is a very imprecise word. Does good software have lots of features, is it free of bugs, or is it an innovative 'I never knew I needed it till I saw it' type of package.
Software need only fall into one or possibly two of the above categories in order to reach the accolade of 'good'. There are even packages in use today that are in mainstream use that are not necessarily good but have just become ubiquitous by default. [Windows Notepad springs to mind -its minimally featured, you can't edit large files with it, yet everyone uses it at some point or other].
There are other packages (e.g. games) which take nowhere near 10 years to develop (Minesweeper is incredibly simple but is a great game and is virtually unchanged since Windows 3.0/1).
Donte Alistair Anderson Roberts - hi son!
Karma: Chameleon
It isn't always worth it.
It is to me. That one thing or other I've skipped in the past always comes back to bite me. I've never had a boss that pressured me on time once they saw that my code didn't break the thing 6 months later when we were all struggling to fix a few pages that the coder didn't take the time to do it right. Also, that occassional wundercode I've pulled off pretty much buys me whatever time I ask for. I guess it's the old saying : Fast, Good, Cheap; pick any two. My way certainly isn't the only way, but I can never pick the check to leave out, because I can't always conceive what the person that uses my code will do with it.
Once in a while I get burned by that long lived program or scope creap that I underestimated and end up with a big program that should of had the checks in place.
And that's why i always build the checks in first. The time saved up front has never, ever, been worth it.
In some situations where I've gone into an existing program, the checks were wrong simply because there was so much code that the developers got lost and ended up with crap.
And thus one of my points. They weren't doing quality work. If they were, the burn would have been much smaller or non-existent.
I understand what you're saying, though. Throw-away code can be written with throw-away techniques. I'm just particularly bad at knowing in advance what's going to be throw-away code.
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.
Hang on to that HP3300C scanner...you're gonna get a really good linux driver for it in 2011.
The semantic content of XML is equivalent to S-expressions, the core data structure of Lisp, which was invented by John McCarthy in 1959.
To a Lisp hacker, XML is S-expressions in drag.
To a Lisp hacker, XML is S-expressions in drag.
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.
-------------------------
-------------------------
"After Careful Consideration, Bush Recommends Oil Drilling" - The Onion
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?
What about the whole Rapid Application Development philosophy?
/cheat/ the example given since you have so much time invested into your platform that you can get a good boost having such a strong underlying development platform?
I think it still applies that in a month I can write a very useful application using something such as Visual Basic or Delphi (Kylix)
The time in development does not have to fall soley on MY shoulders. The Delphi people have spent many years coding the base libraries and IDE for Delphi. How does this entire development philosophy fit into this guys plan?
What about 4Gl's where many years have been spent refining these languages. Many years have been spent thinking of how to make programming flexible (to a degree) and easier. Does this not
I am not implying any such a platform exists I am just stating that it seems to me this is quite feasible with the right tools. Maybe they are not out there yet but they will be some day.
I just think that in software development you will find many rules and philosiphies spring up only to be later invalidated as the nature of the beast changes.
Anyhow, laters.
Jeremy
- 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?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
Linux anyone? started in 1991, really taking off in 2000/2001. Sounds like ten years to me...
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
--
--Got Lists? | Top 95 Star Wars Line
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 ;-)
====
Codeala - Just another mindless drone
Beause Windows is the razor and Office is the razor blades. Notepad and Wordpad are in there to annoy you into buying Office. Check the retail price of Office($580) vs the retail price of Windows ($310). Micrsoft doesn't announce its profits by division or product, but I bet Applications makes more money than Operating Systems.
www.lucernesys.comHorizon: Calendar-based personal finance
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.