In my opinion, we have such buggy software because programmers are rarely given a rigorous spec. to start with and are rarely capable of following it properly when they are, and that the most common languages in use today (C, C++, Java, VB, Perl) are unbelievably poor: they have weak type systems, if any, they have weak abstraction mechanisms, and they have absolutely no mathematical underpinnings, and they are very bad at preventing mistakes
True enough, but the main reason for buggy software in my experience is inadequate testing due to unrealistic deadlines.
I suspect that the number of bugs grows exponentially with the size of the system. Bugs limit either on the size of the system or the speed of development because of additional testing and debugging.
Because systems grow in size as time permits, even if the development tools were inherently less buggy, the systems would simply grow larger until the number of bugs became a limiting factor again.
The result is that even as tools improve, the number of bugs remains fairly constant although the systems may become larger.
I doubt if you could have self-debugging development tools because
the self-debugging routines would necessarily have bugs in them
human error is inherently unpredictable.
The programs that you call unbelievably poor are also unbelievable improvements over other platforms. It is possible that development tools will always be characterized as unbelievably poor.
The question, then, is: what is the standard for adequacy in development tools?
Has everyone forgotten Teledesic? It's well-funded, affordable, and going into operation in 2005.
If Teledesic keeps its promise, 56KB dial-up will be as obsolete as gopher and Lynx.
Web sites should be preparing for universal broadband access the way software developers rely on faster processors and cheap RAM and disk storage. If the history of software is any indication, there is less risk in betting on the future than in clinging to today's technology.
there is a wonderful scientific experiment going on up there and it involves the whole station and the thousands of people making it possible.
All true, but it points out that the space station is a solution looking for a problem.
Looking at the objectives of the space program and the technology that supports it makes one think that the project is somewhat ahead of its time.
The cost of the missions and the risk involved to the astronauts is out of all proportion to what can be gained, even allowing for some progress in international co-operation.
NASA should be looking for ways to drastically simplify the launches to make them cheaper and safer. Some international co-operation in that area would be more productive than in simply co-ordinating the current approach.
If in fact few useful experiments are being performed in space, it would be better to launch robotic devices, which would be cheaper, return more data, risk no lives and still provide the benefits of increased international co-operation that will one day be necessary for a manned program with a real mission.
For the definitive discussion of the right to privacy, see Hanna Arendt's The Human Condition and her distinction between public and private life.
Greatly simplifying her argument, she says that the essence of totalitarianism is the intrusion of the state into the private life of the citizen, in effect abolishing the distinction between public and private. Without a private sphere, there can be no freedom.
Until recently, privacy was protected by mechanical considerations. Aside from outright intrusions by the state, the effort to collect and distribute private information was so expensive that it was impractical.
The digital nature of data now reduces those mechanical barriers that protected privacy so that things in the past that were de facto private now are de facto public. The main threat to privacy is not the state but the irresponsible use of technology. To take just one example, tapping a telephone line was once a complicated process. Now, using readily available scanners, tapping a cell phone or a cordless phone is cheap and easy.
One solution is a new, more precise legal definition of what is private with specified legal sanctions. The effect of this law would permit someone whose private information was revealed or used without his permission to sue for damages. It would also open those who used private information without explicit permission open to criminal charges.
In effect, personal information becomes private property and people can post "No Trespassing" signs on their lives, enforceable by law.
Any number of education theorists used to bemoan the stultifying effects of conventional classroom education. My own experience as a student confirmed those theorists and the fact that a good deal of education occurs in spite of the education system rather than because of it.
Certainly there is no substitute for a good teacher but there is a shortage of good teachers. A computer, whatever its defects as a teaching device, is usually a good alternative to a bad teacher and a good supplement to a mediocre one.
Here is my own conclusion based on 20 years sitting in classrooms versus hundreds of hours sitting in front of a microcomputer: the computer wins. I would suspect that anyone who tried to educate himself using a computer (usually supplemented by a book) would say that he learned more per hour than he learned listening to lectures and preparing for exams.
...it's a bad idea to let the unit tests drive the code instead of vice versa, though, for all the reasons I mentioned in my original post.
If I understand your objection, the XP methodology appears to define unit tests somewhat differently: Creating a unit test helps a developer to really consider what needs to be done. Requirements are nailed down firmly by tests. There can be no misunderstanding a specification written in the form of executable code.
A unit test would appear to be an especially rigorous form of specifications. Does this approach not meet your requirement that production code should be written to the requirements, not to the acceptance tests?
*Acceptance* tests are the ones that are implementation-independent, and XP has precious little to say about them.
Actually, it is fundamental to the methodology. According to extremeprogramming.org: Quality assurance (QA) is an essential part of the XP process. On some projects QA is done by a separate group, while on others QA will be an integrated into the development team itself. In either case XP requires development to have much closer relationship with QA.
There's a whole page on the subject here that suggest "precious little" isn't accurate.
The principles of XP are useful in the design phase of the project. However, instead of interacting with users of the projects, the architect interacts with the developers who are, in effect, the users of the system design.
The article states: With the short feedback loop between developers and users, and a culture that encourages savvy users to add features and fix bugs, a project can evolve in new directions very quickly
Applying that technique in the design phase with developers might similarly correct design errors and allow developers to start thinking about the project before they see a completed design document.
XP techniques could shorten the design phase and reduce design flaws just as XP promises in the development phase. In fact, XP thus applied might work even better in the design phase than in the development phase.
In short, extreme programming is a nice idea, but unless you know EVERY aspect of the application before the first line of code is written, and don't intend on ever releasing a next version, it's a timewaster
This statement does not match the description of XP in the article at all: Most experienced programmers are familiar with the "large scale up front" design approach. XP programming doesn't embrace this approach...
It makes the real world point that not only do user not know everything they need at the beginning of the project, they ask for things that they don't really need very much.
XP claims to have formal methods of dealing with both these issues.
Well, the rest of us just kind of looked at him funny and continued our usual practice of evaluating possibilities and writing modular code.
Most software development methodologies consider giving your colleague funny looks and continuing usual practices as a big red flag. These are defensive psychological techniques for dealing with threatening ideas and are often early indicators of the validity of the ideas.
Slashdot Mirror
True enough, but the main reason for buggy software in my experience is inadequate testing due to unrealistic deadlines.
I suspect that the number of bugs grows exponentially with the size of the system. Bugs limit either on the size of the system or the speed of development because of additional testing and debugging.
Because systems grow in size as time permits, even if the development tools were inherently less buggy, the systems would simply grow larger until the number of bugs became a limiting factor again.
The result is that even as tools improve, the number of bugs remains fairly constant although the systems may become larger.
I doubt if you could have self-debugging development tools because
- the self-debugging routines would necessarily have bugs in them
- human error is inherently unpredictable.
The programs that you call unbelievably poor are also unbelievable improvements over other platforms. It is possible that development tools will always be characterized as unbelievably poor.The question, then, is: what is the standard for adequacy in development tools?
Has everyone forgotten Teledesic? It's well-funded, affordable, and going into operation in 2005.
If Teledesic keeps its promise, 56KB dial-up will be as obsolete as gopher and Lynx.
Web sites should be preparing for universal broadband access the way software developers rely on faster processors and cheap RAM and disk storage. If the history of software is any indication, there is less risk in betting on the future than in clinging to today's technology.
there is a wonderful scientific experiment going on up there and it involves the whole station and the thousands of people making it possible.
All true, but it points out that the space station is a solution looking for a problem.
Looking at the objectives of the space program and the technology that supports it makes one think that the project is somewhat ahead of its time.
The cost of the missions and the risk involved to the astronauts is out of all proportion to what can be gained, even allowing for some progress in international co-operation.
NASA should be looking for ways to drastically simplify the launches to make them cheaper and safer. Some international co-operation in that area would be more productive than in simply co-ordinating the current approach.
If in fact few useful experiments are being performed in space, it would be better to launch robotic devices, which would be cheaper, return more data, risk no lives and still provide the benefits of increased international co-operation that will one day be necessary for a manned program with a real mission.
Consider further that the oldest known human structures are about 5000 years old (in central America, IIRC.)
No, the world's oldest structure is off the coast of Japan.
No, it's a on Malta
I mean Egypt.
Actually, it's north of Tokyo.
Or, is it a wine jar?
For the definitive discussion of the right to privacy, see Hanna Arendt's The Human Condition and her distinction between public and private life.
Greatly simplifying her argument, she says that the essence of totalitarianism is the intrusion of the state into the private life of the citizen, in effect abolishing the distinction between public and private. Without a private sphere, there can be no freedom.
Until recently, privacy was protected by mechanical considerations. Aside from outright intrusions by the state, the effort to collect and distribute private information was so expensive that it was impractical.
The digital nature of data now reduces those mechanical barriers that protected privacy so that things in the past that were de facto private now are de facto public. The main threat to privacy is not the state but the irresponsible use of technology. To take just one example, tapping a telephone line was once a complicated process. Now, using readily available scanners, tapping a cell phone or a cordless phone is cheap and easy.
One solution is a new, more precise legal definition of what is private with specified legal sanctions. The effect of this law would permit someone whose private information was revealed or used without his permission to sue for damages. It would also open those who used private information without explicit permission open to criminal charges.
In effect, personal information becomes private property and people can post "No Trespassing" signs on their lives, enforceable by law.
Any number of education theorists used to bemoan the stultifying effects of conventional classroom education. My own experience as a student confirmed those theorists and the fact that a good deal of education occurs in spite of the education system rather than because of it.
Certainly there is no substitute for a good teacher but there is a shortage of good teachers. A computer, whatever its defects as a teaching device, is usually a good alternative to a bad teacher and a good supplement to a mediocre one.
Here is my own conclusion based on 20 years sitting in classrooms versus hundreds of hours sitting in front of a microcomputer: the computer wins. I would suspect that anyone who tried to educate himself using a computer (usually supplemented by a book) would say that he learned more per hour than he learned listening to lectures and preparing for exams.
Oracle offers some sample code for building a document management system with version control using Oracle IFS here.
If I understand your objection, the XP methodology appears to define unit tests somewhat differently: Creating a unit test helps a developer to really consider what needs to be done. Requirements are nailed down firmly by tests. There can be no misunderstanding a specification written in the form of executable code.
A unit test would appear to be an especially rigorous form of specifications. Does this approach not meet your requirement that production code should be written to the requirements, not to the acceptance tests?
*Acceptance* tests are the ones that are implementation-independent, and XP has precious little to say about them.
Actually, it is fundamental to the methodology. According to extremeprogramming.org: Quality assurance (QA) is an essential part of the XP process. On some projects QA is done by a separate group, while on others QA will be an integrated into the development team itself. In either case XP requires development to have much closer relationship with QA.
There's a whole page on the subject here that suggest "precious little" isn't accurate.
The principles of XP are useful in the design phase of the project. However, instead of interacting with users of the projects, the architect interacts with the developers who are, in effect, the users of the system design.
The article states: With the short feedback loop between developers and users, and a culture that encourages savvy users to add features and fix bugs, a project can evolve in new directions very quickly
Applying that technique in the design phase with developers might similarly correct design errors and allow developers to start thinking about the project before they see a completed design document.
XP techniques could shorten the design phase and reduce design flaws just as XP promises in the development phase. In fact, XP thus applied might work even better in the design phase than in the development phase.
In short, extreme programming is a nice idea, but unless you know EVERY aspect of the application before the first line of code is written, and don't intend on ever releasing a next version, it's a timewaster
This statement does not match the description of XP in the article at all: Most experienced programmers are familiar with the "large scale up front" design approach. XP programming doesn't embrace this approach...
It makes the real world point that not only do user not know everything they need at the beginning of the project, they ask for things that they don't really need very much.
XP claims to have formal methods of dealing with both these issues.
Well, the rest of us just kind of looked at him funny and continued our usual practice of evaluating possibilities and writing modular code.
Most software development methodologies consider giving your colleague funny looks and continuing usual practices as a big red flag. These are defensive psychological techniques for dealing with threatening ideas and are often early indicators of the validity of the ideas.
Stratospheric Processes And their Role in Climate
Scholarly Publishing and Academic Resources Coalition
Space Physics and Astronomy Research Collaboratory
South Pembrokeshire Action with Rural Communities
Social Planning And Research Council of British Columbia
Student Partners in Amphibian and Reptile Conservation
Statewide Pennsylvania Rights Coalition
Scalable Processor ARChitechture