The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Wired says to take away programmer freedoms

Interesting article posted to wired this morning which says that bugs can't be eliminated (which is probably true) and that programmers should have less freedom in programming.

I'm interested in what everyone thinks about that.

 http://www.wired.com/news/technology/bugs/0,2924,69369,00.html?tw=wn_tophead_1
Dave South Send private email
Wednesday, November 09, 2005
 
 
They are already doing this. It's called SOX (Sarbaines-Oxley). Totally useless, kills productivity, and makes a ton of money for the big accounting firms who created the problem to begin with.
John Send private email
Wednesday, November 09, 2005
 
 
It may be viable, in a certain sense.
Often, when we rush through projects, we compell ourselves to write the most trivial code that we know it will work, even if it is not efficent or elegant.
Sevenoaks Send private email
Wednesday, November 09, 2005
 
 
How will my being less free make for fewer bugs? Mistakes aren't caused by freedom.

This is doubleunplussgood.
son of parnas
Wednesday, November 09, 2005
 
 
I think you mean doubleplusungood.

By saying doubleunplus, I'm assuming you mean --, resulting in --good which just means that it's less good than good but still good nonetheless.

Whereas doubleplusungood means that it is the compounding of the inverse of good thereby making it really bad.
Stephen Caldwell Send private email
Wednesday, November 09, 2005
 
 
>They are already doing this. It's called SOX (Sarbaines-Oxley). Totally useless, kills productivity, and makes a ton of money for the big accounting firms who created the problem to begin with.<

well, it's not *entirely* the big 4's fault, although they should shoulder a lot of the blame. the clients strong armed them into doing these sketchy deals by threatening to take their business elsewhere. trust me, not one partner in a big 4 firm wants to go to the big wigs and tell them they lost a big customer.
starving coder
Wednesday, November 09, 2005
 
 
Stephen, how I have lived this long without you?
son of parnas
Wednesday, November 09, 2005
 
 
Wired isn't talking about taking away your freedom to drink Mountain Dew in your cubicle.  Wired is taking about your freedom to make your code jump through unnecessary hoops.  For example, you can do a lot of really ugly and risky stuff by embedding assembly routines within your C program.

I think there's a trade-off involved.  There are cases where you'd purposefully do something... unusual simply because it would take too long to research and integrate the optimal solution.  Unfortunately, the result is an increased chance that a bug will appear.

I think while the article had a good message, it was a really badly written article that meandered all over the place and doesn't propose any solutions.
Anonymous Coward
Wednesday, November 09, 2005
 
 
In the shadow of SOX, I think that the future will involve some sort of certification or licensure. Just like an engineering firm will need to have a licensed PE on staff to sign documents, there will end up being some scapegoat who will "sign" code. Publically traded companies need a Certified Public Accountant to sign off on some financial documents.

We can't get close to bug-free code until we can get the industry away from Death Marches.

"...take away programmer freedoms"
The freedom to release code affected by buffer overflows?
The freedom to make faulty assumptions?
Peter
Wednesday, November 09, 2005
 
 
I think they spelled Dijkstra wrong.
Ryan Phelps Send private email
Wednesday, November 09, 2005
 
 
Is your belief that they think we "should have less freedom in programming" just because they mentioned type safety as a way or eliminating bugs? Anyway, I don't think the essence of the article was that they want to to emasculate programmers; it was basically that bugs these days are impossible to prevent.
NetFreak Send private email
Wednesday, November 09, 2005
 
 
Perhaps Simson Garfinkel equates less freedom with concepts such as managed code and type-safety (which are not the same thing and there is confusion about this in this article).  Or perhaps Garfinkel doesn't know what "less freedom" means, which is why he didn't elaborate on it.

Anway, off to find William Wallace....
Paul Norrie Send private email
Wednesday, November 09, 2005
 
 
Yes, it was a badly written article.

They classified bugs as either typographic (errors in syntax or program logic) or conceptual (errors in assumptions, requirements, constraints, environment, etc).  "Programmer Freedoms" really only applies to the first category.  Conceptual errors are irrelevant.

The real question is, "do we give programmers the freedom to make mistakes?"  Do we let them write in C which allows for buffer overruns, or do we limit them to languages that mitigate the consequences of buffer overruns?

And as I said before, there are other factors involved in what programmers should be allowed to do, not just the possibility of bugs.
Anonymous Coward
Wednesday, November 09, 2005
 
 
Err...

To clarify, yes.  I thought the point of the argument was that bugs are inevitable.  Dave South also wondered if we should make an attempt to reduce the number of bugs - and how?
Anonymous Coward
Wednesday, November 09, 2005
 
 
Edsger W. Dijkstra is spelled correctly.
Karel Thönissen Send private email
Wednesday, November 09, 2005
 
 
I think I'm being a little sensitive to the Wired article because I just finished reading Joel's book (...Diverse and Occassionally Related Matters...). Joel talks about how rigid structure seems to ruin a project, not help it (Sigma Six, etc). The Wired author indicates that less freedom is necessary to reduce bugs.

The key phrase that worries me is: "That's why Jackson and other specialists believe that the secret to having fewer bugs lies in taking much of that freedom away."

If programming is a creative endeavor, it stands to reason that limiting a developer incorrectly would cause more harm than it solves.

Which 'freedoms' should be limited, if any?
Dave South Send private email
Wednesday, November 09, 2005
 
 
"Ultimately, bugs in today's programs are not the result of too little testing, says Jackson. Instead, they're caused by too much freedom given to programmers. With the freedom to be creative comes the freedom to make mistakes. That's why Jackson and other specialists believe that the secret to having fewer bugs lies in taking much of that freedom away."


I agree with several other posters.

The article rambles & does NOT even follow up the above paragraph to detail how Dr. Daniel Jackson (SG-1?) proposes to take "much of [their] freedom away".  What freedoms?

Are these freedoms related to programming languages, design & implementation methods, what?
Ian Johns
Wednesday, November 09, 2005
 
 
So it will be a case of 'to do X you must use algorithm Y' and it must use one of patterns 'A,B,C' and be run on one of the following approved appservers: Z.

N days of testing by P people holding certification Q are required before a product addressing requirent E may be released.

Good news if you own the patent for Y and A,B,C I suppose, or sell licenses for Z, or are an outsourcer providing the N P's.

I really can see how this sort of thing would really suit big and uninnovative software and consulting companies and how they would really love to force it upon everyone. For a start it would destroy all those annoying smaller ISVs that might dare to threaten their devine right to make huge profit margins.
Domainless
Wednesday, November 09, 2005
 
 
I would also like to seem so conrolled studies that show this approach works. Then people will adopt it willingly and you don't need to legislate. For now it's just more bias being confused with fact.
son of parnas
Thursday, November 10, 2005
 
 
So, is it fair to say that the Wired article was buggy as well.

Perhaps writers should have their freedoms limited as well.
vic
Thursday, November 10, 2005
 
 
They fixed the spelling of Dijkstra.  When I first read the article it was missing the 'k'.

Wow I'm a geek, I just put a letter in tick marks like it's C code.  Wow you're a geek for thinking that's normal.
Ryan Phelps Send private email
Friday, November 11, 2005
 
 
I think some of you misread it... the "freedom" they're talking about is the "freedom" of code to cause damage beyond its boundaries, and the solution mentioned by the MIT prof is actually a long-time mantra of the MIT comp sci program which is that errors will try to propagate across a system, so each element must be built robust enough to both detect and suppress them, as well as be computationally "correct" for all possible inputs. Thus when an occasional element is NOT robust because of the inevitable bug, it is unlikely to take down the elements around it (that depend on it or vice versa). A robust computing platform they're alluding to would mean if the OS crashes, it wouldn't crash your app. Your app might just not have access to disk I/O for example until the operator could do a clean reboot, or could reboot it itself.

I think if the writing seems muddied it was probably because Wired chopped it up for "mass" consumption. I went to school with the author at MIT and remember him as a bright guy who was always doing work at the Media Lab and knows his technical stuff... (and no I'm not him).
Ron
Friday, November 11, 2005
 
 
I suppose (and hope!) that by "reducing the freedom" of the programmer he means reducing the degrees of freedom in the language. ( http://blog.intentionalsoftware.com/intentional_software/2005/05/feature_x_is_co.html ) In other words, using the appropriate tools and levels of abstraction for the job.
Rubinelli Send private email
Tuesday, November 15, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz