Slashdot Mirror

Anyhow, security was just an example. Suppose your first draft of the source code is just poorly formatted and doesn't have enough comments? Maybe you don't want everybody to get a bad first impression.

XP rule: all code is written according to a standard. So no, that's not a valid excuse. =)

I'm also a little lost as to the logic of your post. You start off talking about security, and then start talking about bugs. These are very different things.

Not usually. Look at any of the security boards... my estimate is that 80% of security holes are related to simple bugs, with the remaining 20% being architectural flaws.

If it is a simple bug, then my previous post applies -- why should it exist at all? If it is some deeper, "archetectural" level security issue, then it should certainly not be held secret with an insecure binary being released.

I can't imagine a person willfully advocating the release of an insecure binary without source for the purposes of fixing the insecurities in the background.

That's just messed up.

3. ... Suppose you write an initial version that is full of security holes, but that does demonstrate some key functionality. You might want to release a binary, then spend a month fixing the security, then open-source the project.

Oof. That's a very foolish thing to advise. Though I am not the first to rant against "Security through Obscurity", I'm going to have to speak against this one for sure.

Just so I get this straight... you're advocating giving a person a binary with security holes, and not informing them (either through source or English description) what those holes are? That's so absurd!

I am guessing that you are unaware of such tools as strace and ltrace, which would most likely leave the security hole in plain view, anyway.

But that's not even the half of it.

My real question is this: Why are the bugs there in the first place?

I am absolutely tired of buggy software. It should be (and as far as I'm concerned, is) a thing of the past. I am unable to understand why a person would write a line of buggy code, unless of course they don't understand how that can be done.

The idea is that you develop in micro-iterations... every time you want to add a feature, you write a test first, then you implement the interface until the tests all pass. When you are done, you have the guarantee that everything works, and that it will continue to work (because you never remove the test).

Other XP tenets that would very much help here are:

1. Simple Design
2. YAGNI (You Aren't Gonna Need It.)
3. Refactoring
4. and of course:
5. Pair Programming, though it may not be possible in every case

I have a good guess as to what your first rebuttal is going to be, "But what about experimental features?", as in features that are prototypical. In this case the practice of Spike Solutions becomes relevant.

None of this is just kooky theories. Well, they are that =)... but they're more -- people (including myself) are actually doing this and it is working. Since I've begun my adoption of the XP process, I've developed better code that is nearly 100% bug free at the end of each iteration, and I've developed it faster.

I realize that I linked more than I spoke, but I feel that the XP practices speak for themselves against the mindsets that I'm seeing in yours and other posts.

- Dr. Barson

3. ... Suppose you write an initial version that is full of security holes, but that does demonstrate some key functionality. You might want to release a binary, then spend a month fixing the security, then open-source the project.

Oof. That's a very foolish thing to advise. Though I am not the first to rant against "Security through Obscurity", I'm going to have to speak against this one for sure.

Just so I get this straight... you're advocating giving a person a binary with security holes, and not informing them (either through source or English description) what those holes are? That's so absurd!

I am guessing that you are unaware of such tools as strace and ltrace, which would most likely leave the security hole in plain view, anyway.

But that's not even the half of it.

My real question is this: Why are the bugs there in the first place?

I am absolutely tired of buggy software. It should be (and as far as I'm concerned, is) a thing of the past. I am unable to understand why a person would write a line of buggy code, unless of course they don't understand how that can be done.

The idea is that you develop in micro-iterations... every time you want to add a feature, you write a test first, then you implement the interface until the tests all pass. When you are done, you have the guarantee that everything works, and that it will continue to work (because you never remove the test).

Other XP tenets that would very much help here are:

1. Simple Design
2. YAGNI (You Aren't Gonna Need It.)
3. Refactoring
4. and of course:
5. Pair Programming, though it may not be possible in every case

I have a good guess as to what your first rebuttal is going to be, "But what about experimental features?", as in features that are prototypical. In this case the practice of Spike Solutions becomes relevant.

None of this is just kooky theories. Well, they are that =)... but they're more -- people (including myself) are actually doing this and it is working. Since I've begun my adoption of the XP process, I've developed better code that is nearly 100% bug free at the end of each iteration, and I've developed it faster.

I realize that I linked more than I spoke, but I feel that the XP practices speak for themselves against the mindsets that I'm seeing in yours and other posts.

- Dr. Barson

3. ... Suppose you write an initial version that is full of security holes, but that does demonstrate some key functionality. You might want to release a binary, then spend a month fixing the security, then open-source the project.

Oof. That's a very foolish thing to advise. Though I am not the first to rant against "Security through Obscurity", I'm going to have to speak against this one for sure.

Just so I get this straight... you're advocating giving a person a binary with security holes, and not informing them (either through source or English description) what those holes are? That's so absurd!

I am guessing that you are unaware of such tools as strace and ltrace, which would most likely leave the security hole in plain view, anyway.

But that's not even the half of it.

My real question is this: Why are the bugs there in the first place?

I am absolutely tired of buggy software. It should be (and as far as I'm concerned, is) a thing of the past. I am unable to understand why a person would write a line of buggy code, unless of course they don't understand how that can be done.

The idea is that you develop in micro-iterations... every time you want to add a feature, you write a test first, then you implement the interface until the tests all pass. When you are done, you have the guarantee that everything works, and that it will continue to work (because you never remove the test).

Other XP tenets that would very much help here are:

1. Simple Design
2. YAGNI (You Aren't Gonna Need It.)
3. Refactoring
4. and of course:
5. Pair Programming, though it may not be possible in every case

I have a good guess as to what your first rebuttal is going to be, "But what about experimental features?", as in features that are prototypical. In this case the practice of Spike Solutions becomes relevant.

None of this is just kooky theories. Well, they are that =)... but they're more -- people (including myself) are actually doing this and it is working. Since I've begun my adoption of the XP process, I've developed better code that is nearly 100% bug free at the end of each iteration, and I've developed it faster.

I realize that I linked more than I spoke, but I feel that the XP practices speak for themselves against the mindsets that I'm seeing in yours and other posts.

- Dr. Barson

3. ... Suppose you write an initial version that is full of security holes, but that does demonstrate some key functionality. You might want to release a binary, then spend a month fixing the security, then open-source the project.

Oof. That's a very foolish thing to advise. Though I am not the first to rant against "Security through Obscurity", I'm going to have to speak against this one for sure.

Just so I get this straight... you're advocating giving a person a binary with security holes, and not informing them (either through source or English description) what those holes are? That's so absurd!

I am guessing that you are unaware of such tools as strace and ltrace, which would most likely leave the security hole in plain view, anyway.

But that's not even the half of it.

My real question is this: Why are the bugs there in the first place?

I am absolutely tired of buggy software. It should be (and as far as I'm concerned, is) a thing of the past. I am unable to understand why a person would write a line of buggy code, unless of course they don't understand how that can be done.

The idea is that you develop in micro-iterations... every time you want to add a feature, you write a test first, then you implement the interface until the tests all pass. When you are done, you have the guarantee that everything works, and that it will continue to work (because you never remove the test).

Other XP tenets that would very much help here are:

1. Simple Design
2. YAGNI (You Aren't Gonna Need It.)
3. Refactoring
4. and of course:
5. Pair Programming, though it may not be possible in every case

I have a good guess as to what your first rebuttal is going to be, "But what about experimental features?", as in features that are prototypical. In this case the practice of Spike Solutions becomes relevant.

None of this is just kooky theories. Well, they are that =)... but they're more -- people (including myself) are actually doing this and it is working. Since I've begun my adoption of the XP process, I've developed better code that is nearly 100% bug free at the end of each iteration, and I've developed it faster.

I realize that I linked more than I spoke, but I feel that the XP practices speak for themselves against the mindsets that I'm seeing in yours and other posts.

- Dr. Barson

3. ... Suppose you write an initial version that is full of security holes, but that does demonstrate some key functionality. You might want to release a binary, then spend a month fixing the security, then open-source the project.

Oof. That's a very foolish thing to advise. Though I am not the first to rant against "Security through Obscurity", I'm going to have to speak against this one for sure.

Just so I get this straight... you're advocating giving a person a binary with security holes, and not informing them (either through source or English description) what those holes are? That's so absurd!

I am guessing that you are unaware of such tools as strace and ltrace, which would most likely leave the security hole in plain view, anyway.

But that's not even the half of it.

My real question is this: Why are the bugs there in the first place?

I am absolutely tired of buggy software. It should be (and as far as I'm concerned, is) a thing of the past. I am unable to understand why a person would write a line of buggy code, unless of course they don't understand how that can be done.

The idea is that you develop in micro-iterations... every time you want to add a feature, you write a test first, then you implement the interface until the tests all pass. When you are done, you have the guarantee that everything works, and that it will continue to work (because you never remove the test).

Other XP tenets that would very much help here are:

1. Simple Design
2. YAGNI (You Aren't Gonna Need It.)
3. Refactoring
4. and of course:
5. Pair Programming, though it may not be possible in every case

I have a good guess as to what your first rebuttal is going to be, "But what about experimental features?", as in features that are prototypical. In this case the practice of Spike Solutions becomes relevant.

None of this is just kooky theories. Well, they are that =)... but they're more -- people (including myself) are actually doing this and it is working. Since I've begun my adoption of the XP process, I've developed better code that is nearly 100% bug free at the end of each iteration, and I've developed it faster.

I realize that I linked more than I spoke, but I feel that the XP practices speak for themselves against the mindsets that I'm seeing in yours and other posts.

- Dr. Barson

3. ... Suppose you write an initial version that is full of security holes, but that does demonstrate some key functionality. You might want to release a binary, then spend a month fixing the security, then open-source the project.

Oof. That's a very foolish thing to advise. Though I am not the first to rant against "Security through Obscurity", I'm going to have to speak against this one for sure.

Just so I get this straight... you're advocating giving a person a binary with security holes, and not informing them (either through source or English description) what those holes are? That's so absurd!

I am guessing that you are unaware of such tools as strace and ltrace, which would most likely leave the security hole in plain view, anyway.

But that's not even the half of it.

My real question is this: Why are the bugs there in the first place?

I am absolutely tired of buggy software. It should be (and as far as I'm concerned, is) a thing of the past. I am unable to understand why a person would write a line of buggy code, unless of course they don't understand how that can be done.

The idea is that you develop in micro-iterations... every time you want to add a feature, you write a test first, then you implement the interface until the tests all pass. When you are done, you have the guarantee that everything works, and that it will continue to work (because you never remove the test).

Other XP tenets that would very much help here are:

1. Simple Design
2. YAGNI (You Aren't Gonna Need It.)
3. Refactoring
4. and of course:
5. Pair Programming, though it may not be possible in every case

I have a good guess as to what your first rebuttal is going to be, "But what about experimental features?", as in features that are prototypical. In this case the practice of Spike Solutions becomes relevant.

None of this is just kooky theories. Well, they are that =)... but they're more -- people (including myself) are actually doing this and it is working. Since I've begun my adoption of the XP process, I've developed better code that is nearly 100% bug free at the end of each iteration, and I've developed it faster.

I realize that I linked more than I spoke, but I feel that the XP practices speak for themselves against the mindsets that I'm seeing in yours and other posts.

- Dr. Barson

3. ... Suppose you write an initial version that is full of security holes, but that does demonstrate some key functionality. You might want to release a binary, then spend a month fixing the security, then open-source the project.

Oof. That's a very foolish thing to advise. Though I am not the first to rant against "Security through Obscurity", I'm going to have to speak against this one for sure.

Just so I get this straight... you're advocating giving a person a binary with security holes, and not informing them (either through source or English description) what those holes are? That's so absurd!

I am guessing that you are unaware of such tools as strace and ltrace, which would most likely leave the security hole in plain view, anyway.

But that's not even the half of it.

My real question is this: Why are the bugs there in the first place?

I am absolutely tired of buggy software. It should be (and as far as I'm concerned, is) a thing of the past. I am unable to understand why a person would write a line of buggy code, unless of course they don't understand how that can be done.

The idea is that you develop in micro-iterations... every time you want to add a feature, you write a test first, then you implement the interface until the tests all pass. When you are done, you have the guarantee that everything works, and that it will continue to work (because you never remove the test).

Other XP tenets that would very much help here are:

1. Simple Design
2. YAGNI (You Aren't Gonna Need It.)
3. Refactoring
4. and of course:
5. Pair Programming, though it may not be possible in every case

I have a good guess as to what your first rebuttal is going to be, "But what about experimental features?", as in features that are prototypical. In this case the practice of Spike Solutions becomes relevant.

None of this is just kooky theories. Well, they are that =)... but they're more -- people (including myself) are actually doing this and it is working. Since I've begun my adoption of the XP process, I've developed better code that is nearly 100% bug free at the end of each iteration, and I've developed it faster.

I realize that I linked more than I spoke, but I feel that the XP practices speak for themselves against the mindsets that I'm seeing in yours and other posts.

- Dr. Barson

I'm currently building some server-side Java web applications. Since the Java Servlet stuff is inherently multi-threaded, I have indeed occasionally been reminded that multi-threaded applications are tricky.

A few months back, we purchased a suite of tools from an outfit called Sitraka (nee KLGroup). They have three products that are part of the JProbe Suite, a CPU and memory profiler, a thread analysis program, and a code coverage tool.

These are all good tools; when I was having some problems that I suspected were due to my less-than-perfect understanding of threading, I used their thread analysis tool under simulated load, and it immediately identfied my race condition, plus a couple more potential races I hadn't noticed yet.

(This is a little off-topic, but I have to mention that their memory/CPU profiler is, pardon my french, fucking awesome; it is the best thing I have ever seen for visualizing the interior structure of a running program. After a day with the profiler, my Java code was substantially faster than the C it was replacing, despite having more features and being more secure.)

Another tool I'm very pleased with is JUnit, a unit-testing framework. If you're interested in trying out the Extreme Programming-style approach to testing (wherein you make automated, integrated unit tests that are run more or less continuously) then this is for you. And if you are having so many problems with bugs that you are considering changing languages, then I would strongly recommend that you do this. Good unit tests slow initial writing down a little, and save you extraordinary amounts of time and agony later.

Oh, and run out right now and buy several copies of Code Complete and Rapid Development for the team. If you are having such large problems on the project, the problem is probably not with your choice of debugger. These books will help you figure out what the problem actually is, and give you all sorts of solutions.

--

For the record, and I don't have any financial interest in any of the things I've mentioned here; I just use 'em and like 'em.

I'm currently building some server-side Java web applications. Since the Java Servlet stuff is inherently multi-threaded, I have indeed occasionally been reminded that multi-threaded applications are tricky.

A few months back, we purchased a suite of tools from an outfit called Sitraka (nee KLGroup). They have three products that are part of the JProbe Suite, a CPU and memory profiler, a thread analysis program, and a code coverage tool.

These are all good tools; when I was having some problems that I suspected were due to my less-than-perfect understanding of threading, I used their thread analysis tool under simulated load, and it immediately identfied my race condition, plus a couple more potential races I hadn't noticed yet.

(This is a little off-topic, but I have to mention that their memory/CPU profiler is, pardon my french, fucking awesome; it is the best thing I have ever seen for visualizing the interior structure of a running program. After a day with the profiler, my Java code was substantially faster than the C it was replacing, despite having more features and being more secure.)

Another tool I'm very pleased with is JUnit, a unit-testing framework. If you're interested in trying out the Extreme Programming-style approach to testing (wherein you make automated, integrated unit tests that are run more or less continuously) then this is for you. And if you are having so many problems with bugs that you are considering changing languages, then I would strongly recommend that you do this. Good unit tests slow initial writing down a little, and save you extraordinary amounts of time and agony later.

Oh, and run out right now and buy several copies of Code Complete and Rapid Development for the team. If you are having such large problems on the project, the problem is probably not with your choice of debugger. These books will help you figure out what the problem actually is, and give you all sorts of solutions.

--

For the record, and I don't have any financial interest in any of the things I've mentioned here; I just use 'em and like 'em.

Extreme Programming, is just the latest buzz word for what was RAD, and before that what was simply good practice/procedures...

This reminds me of the claim of extreme programming that working in pairs increases productivity. I think it's just because you feel more guilty screwing around when the other guy is working, so you both end up working. Kind of a prisoners' dilemma, I guess.

• The vast majority of software is a question of implementation, not algorithmic logic. It seems like it's a lot more complicated to prove implementation than algorithms.
• There are currently a very small number of people with both the analytical skills and the severely rational temperment required to do these proofs. So relying on that for QA seems like it would put a really nasty bottleneck on the process.
• I have this sneaking suspicion that any abstraction of code -- UML, flowcharts, proofs -- is only that: an abstraction. And that correctness (or, more likely, bugginess) lives in the code, and in the code alone, so that's where you have to weed it out.
• It just seems like it'd be no fun. Don't get me wrong; I try to make my code clean and maintainable and all that. But if I had to run it all through some tortuous logic to prove to myself that it works, I don't think I'd ever want to code at all.

I personally think Extreme Programming holds a high amount of promise. At times it seems like dogma, but in general its principles make a lot of sense to me. Keep those feedback loops tight. Fixed requirements are a myth, so don't ever design for fixed requirements. Well-maintained test cases are as important as coding.

(Of course, I work in a web shop, and the definition of QA in our industry is "Those colors look right in that Photoshop mockup", so it's not like I really know from experience. Just some random thoughts.)

It is perfectly valid and is in fact a major component of any programmers job (and it SHOULD be as well).

I'd have to disagree with that. If a programmer is doing his job right, then he should spend time at the begining setting up tests but that's mainly it. Spending a lot of time after the fact trying to ensure the job was actually done correctly, or trying to track down why it wasn't should not be a major part of his job.

I know XP takes this to the extreme, but the basic principle holds true. If you're spending too much time debugging, then you might not be spending enough time on solid design and correct coding or even just determing requirements before working.

In other industries this is known as "measure twice, cut once" and the like.

It takes a lot of what Greenspun says and turns it on its ear.

Just in case you want to know what it is...
_________________________

There is a methodology called Extreme Programming which introduces a concept called Pair Programming. A technique like Pair Programming would I think be useful for this kind of problem. Certainly, when I get a block like this I try to talk to other people about the problem - often the simple act of explaining it can crystalize my thought.

Asmodeus

There is a methodology called Extreme Programming which introduces a concept called Pair Programming. A technique like Pair Programming would I think be useful for this kind of problem. Certainly, when I get a block like this I try to talk to other people about the problem - often the simple act of explaining it can crystalize my thought.

Asmodeus

The Mozilla project sounds great to start -- open source, new layout engine, etc. The problem is that they added way too many features.

In modern programming, a new methodology has arisen which allows for very fast-to-market products. All of the mozilla people should check out ' extreme programming '.

The basic idea is to get a product out with the minimum feature set as early as possible so users get a chance to use it and give feedback. For mozilla: drop newsgroups (crappy newsreader anyway), drop IM (add it later), drop HTML editing, drop EVERYTHING except the browser!

I am forced to use the only usable browser on my system: IE5 for Mac. NetScape/Mozilla is an abomination.

I swear to god with 3 programmers and 3 months of time I could come up with a standards compliant browser that kicked the crap out of IE (standard's-wise that is) and was comparable on UI. (IE is pretty nice). But I would concentrate on the browser, not on the other crap like news, editing, or even skins.

It seems that Mozilla bit into this whole bit about a few techno-weenies (sorry /. readers) that think skins are necessary because they haven't figured out any other way to express their distinctness in a faceless online world. For most of the world, they can care less about skins -- they want a browser that WORKS!

They need to FOCUS! FOCUS! FOCUS! on a browser. Extreme programming lives!

This is somewhat similar to the softwear engineering methodology known as "Extreme Programming"

One of the main tenents of Extreme Programming is constant refactoring (ie, you see something that could be done better another way, you fix it straight away)

The other main point of extreme programming are: Always do the simplest thing that will work, and have proper, automatic test suites to constantly test your work.

Have a look at The Extreme Programming Web Site to learn more.

One of the emerging trends in academic "out there" approaches to software engineering has been moving patterns from architecture (sofware and housing) to behavioral practice, of which this is a negative example. For positive examples, there is an intesting website I ran across the other day about a concept called "Extreme Programming". This concept wouldn't scale to the sort of distributed development done for OSS, but portions of it might. In any case, documenting robust positive patterns for OSS development sounds like an interesting project.

For a gentle introduction, check out ExtremeProgramming.org. They also have a nice on-going column about developing an "extreme"-style coffee maker.

A new methodology called Extreme Programming (XP) has been emerging. The idea which is relevent here is to allow customers to make business decisions and technical people make technical decisions. Also of note is the methodologies emphasis on getting developers to work together as a cooperative team. As well as ways to make code more legable without lots of (obsolete) comments. An introduction is provided at ExtremeProgramming.Org