I agree that this is just a fancy assert mechanism. But a lot of people are claiming that printf is the best debugger. Sometimes it't the best one can do. Other times a real debugger is the only efficient way. Many programmers that I respect, and I also, use the debugger as a sanity checker. Whenever I code up a new module and it has passed basic functionality tests I fire up my code in a debugger and do a thorough walk through. I find a good many subtle flaws this way, saving a great deal of time in the intensive testing and later QA cycles. I recommend this as a best practice to any programmer.
Here, here. ESR original letter was on the impolite side to be sure, but not outrageously so. Simon Phipps's reply, however, was at least as impolite; if I were CEO at Sun I'd give him a good dressing down. It's the job of every outward facing employee of a company to treat possible customers (even ESR and certainly the thousands of open source users) with respect, or at least silence, no matter what the provocation.
And this is but an instance of Sun's attitude to its customer base and partners. As a developer at an enterprise software company selling a product that mostly shipped for Solaris I was fed up to the gills with Sun's lack of helpfulness when we hit snags with Solaris. I mean, we were selling about 300 Sun servers for them every year and they wouldn't take the time to help us out when we ran into Solaris obscurities. Luckily we had a smart team and were always able to sort out difficulties without Sun's help, but fairly early on we stopped even trying to get help.
Because of human nature and because of the extreme complexity of the ideas we attempt to encapsulate in non-trivial software, buglessness is not an achievable goal, regardless of the methodology of the day. The interviewee seems to think that there is some magic bullet waiting (in new tools or methodologies I guess). This shows a fundamental rift between her and reality, and makes her opinions fundamentally suspect.
The goal in any real software project is to meet customer's (and I use that in the broadest sense) expectations adequately. What is adequate? That depends on the software. A user of a word processor for instance is likely to not mind a handful of UI bugs or an occasional crash. A sales organization is going to expect 24/7 performance from their Sales Automation Software.
The canny programmer (or programming group) should aim herself to produce software that is "good enough" for the target audience, with, perhaps, a little extra for safety's sake (and programmer pride).
Of course their are real differences among the tools and methodologies used in getting the most "enough" per programmer hour. Among the one's I've come to believe are:
1. Use the most obvious implementation of any module unless performance requirements prohibit.
2. Have regular code-reviews, preferably before every check-in. I've been amazed at how this simple policy reduces the initial bug load of code. Having to explain one's code to another programmer has a very salutary effect on code quality.
3. Hire a small number of first class programmers rather than a larger number of lesser programmers. In my experience 10% of the programmers tend to do 90% of the useful work in large software projects.
4. Try to get the technical staff doing as much programming as possible. Don't bog them down with micromanagement, frequent meetings, complex coding conventions, arbitrary documentation rules, and anything else that slows them down.
The first thing I'd like to know is how much popular support there is for this initiative (a word that hides a multitude of sins)? I assume that there must be a good bit since MPs do like to get elected. Second what is the cause of the popular support? Does Britain have a run-away traffic death rate or something like that? Curious.
XML is just tagged s-lists.
on
Effective XML
·
· Score: 4, Insightful
XML is highly overrated and generally over-used. Admittedly XML + CSS is better than html, but beyond that its only reasonable use is as a generalized syntax for configuration files, and as such does a good job, or at least I've had success using it that way in the past. Many (if not most) of its other uses are just poor program design. Soap is an extremely silly idea. Why use XML for a marshalling syntax for RPC? It's slower, bulkier, and just a bad choice in comparison to a binary marshalling mechanism. Now as a syntax for an RPC's IDL XML makes a lot of sense, but not as a transport.
Glad to get that off my chest. I have a bitter history with XML. I was the first person at my former company to bring XML in as a uniform configuration file format for our product, but then found myself a couple of years later forced into adding XML specific features to the filesystem that was the core of our company's product. I spent a week thinking about the idea, and concluded that it was a bad one. Thus followed a long (and fruitless) battle with management to scratch the plan. The end result was a technically nifty but useless set of features. The work remains unreleased for lack of customer interest. At least I get a bit of "I told you so." pleasure.
In my years in the commercial software development world--admittedly 2 companies, both startups--we've never considered outsourcing any work overseas. We did outsource I18N work--to an American company--because not one of us programmers wanted to touch I18N. The universal experience of all the programmers I know in the USA is that outsourcing _significant_ software development overseas results in universally disastrous code. It's may sound harsh but the US still has 90% of the really good coders, and any US company that wants to succeed is best advised to stick with US operations. Of course of the really good coders in the US a significant fraction are not originally American. But, I don't see the balance of talent changing any time soon.
Work your way through all the Nobel prize winners and count the number who were not married when they were doing their nobel prize winning works. I work at Stanford Medical School. The two prizewinners I was familiar with, both in the biochemistry department, were Arthur Kornberg, and Paul Berg. Both of whom were married well before their nobel prize winning work. Let's add (and I may get a few wrong) Richard Feynmann, Pierre and Marie Curie, Niehls Bohr, Robert B. Woodward. Go to the official nobel site and read the biographies of the winners. Most were married.
that make sense in a commercial environment is the good enough principle. What constitutes good enough is what calls for good judgement. If you're writing a server app that is expected to be mission critical, good enough is very good. If you're writing a one off desktop app, good enough can be quite sloppy. IMHO
Why not put the onus of mail delivery on E-mail clients and reserve SMTP servers for mail reception only? SMTP relaying is convenient, because of retries etc, but not essential. That functionality wouldn't be too difficult to incorporate into existing E-mail clients. Heck, even MS could probably manage to add such features to Outlook;) I'm probably missing something obvious that would make this untenable. Just remember there are no stupid questions only stupid people.
First of all if you're paying $20 dollars an album you're paying too much. Try $10 - $16. You also must be very young. I started buying albums when I was 12 and am now 40. I have about 500 albums vinyl and about 300 CDs, and have never been rich. Time makes up for a lot of things.
As soon as there is a better search service than Google, Google will have problems. However, to do that a company needs to be more clever than Google. I think that will be a hard job. A trivial example of the Google folk's cleverness is the "ticker symbol", "I feel lucky" trick. Go ahead try it on "IWOV" (I used to work there).
Then you haven't written enough tests. Or you're trying to integrate too much at once.
If you do test-first development [c2.com] and continuous integration [c2.com] (backed up with good black-box integration testing), then the number of bugs you get should be low. In my experience, that's circa one shipped bug per man-month.
In theory methodologies like this are good. In practice (at least in a startup environment) developers simply don't have time to follow such practice. Yes, you have time to write unit tests for certain complex and central objects but not for everything. You also have time to write (for servers) stress and functionality test clients. In general you just have to rely on smart programmers and frequent code reviews.
I come not to bash digital. I have a 5700 and love it. It's wonderful for color work and for most practical purposes is just as good as film. However if one is a serious photographer working in black and white, digital doesn't quite cut it, but not for reasons of resolution (though I don't think anyone's manufacturing a camera with the resolution of Tech-Pan on 4x5;) or dynamic range but because there is no output medium (that I know of) that can produce the beauty, resolution, dynamic range of a silver (or platinum/palladium) print. Perhaps in the future there will be service angencies who will print b&w from digital originals, but the market for such a service is so small...
Slashdot Mirror
I agree that this is just a fancy assert mechanism. But a lot of people are claiming that printf is the best debugger. Sometimes it't the best one can do. Other times a real debugger is the only efficient way. Many programmers that I respect, and I also, use the debugger as a sanity checker. Whenever I code up a new module and it has passed basic functionality tests I fire up my code in a debugger and do a thorough walk through. I find a good many subtle flaws this way, saving a great deal of time in the intensive testing and later QA cycles. I recommend this as a best practice to any programmer.
Here, here. ESR original letter was on the impolite side to be sure, but not outrageously so. Simon Phipps's reply, however, was at least as impolite; if I were CEO at Sun I'd give him a good dressing down. It's the job of every outward facing employee of a company to treat possible customers (even ESR and certainly the thousands of open source users) with respect, or at least silence, no matter what the provocation.
And this is but an instance of Sun's attitude to its customer base and partners. As a developer at an enterprise software company selling a product that mostly shipped for Solaris I was fed up to the gills with Sun's lack of helpfulness when we hit snags with Solaris. I mean, we were selling about 300 Sun servers for them every year and they wouldn't take the time to help us out when we ran into Solaris obscurities. Luckily we had a smart team and were always able to sort out difficulties without Sun's help, but fairly early on we stopped even trying to get help.
Because of human nature and because of the extreme complexity of the ideas we attempt to encapsulate in non-trivial software, buglessness is not an achievable goal, regardless of the methodology of the day. The interviewee seems to think that there is some magic bullet waiting (in new tools or methodologies I guess). This shows a fundamental rift between her and reality, and makes her opinions fundamentally suspect.
The goal in any real software project is to meet customer's (and I use that in the broadest sense) expectations adequately. What is adequate? That depends on the software. A user of a word processor for instance is likely to not mind a handful of UI bugs or an occasional crash. A sales organization is going to expect 24/7 performance from their Sales Automation Software.
The canny programmer (or programming group) should aim herself to produce software that is "good enough" for the target audience, with, perhaps, a little extra for safety's sake (and programmer pride).
Of course their are real differences among the tools and methodologies used in getting the most "enough" per programmer hour. Among the one's I've come to believe are:
1. Use the most obvious implementation of any module unless performance requirements prohibit.
2. Have regular code-reviews, preferably before every check-in. I've been amazed at how this simple policy reduces the initial bug load of code. Having to explain one's code to another programmer has a very salutary effect on code quality.
3. Hire a small number of first class programmers rather than a larger number of lesser programmers. In my experience 10% of the programmers tend to do 90% of the useful work in large software projects.
4. Try to get the technical staff doing as much programming as possible. Don't bog them down with micromanagement, frequent meetings, complex coding conventions, arbitrary documentation rules, and anything else that slows them down.
5. Test, test, test!
The first thing I'd like to know is how much popular support there is for this initiative (a word that hides a multitude of sins)? I assume that there must be a good bit since MPs do like to get elected. Second what is the cause of the popular support? Does Britain have a run-away traffic death rate or something like that? Curious.
XML is highly overrated and generally over-used. Admittedly XML + CSS is better than html, but beyond that its only reasonable use is as a generalized syntax for configuration files, and as such does a good job, or at least I've had success using it that way in the past. Many (if not most) of its other uses are just poor program design. Soap is an extremely silly idea. Why use XML for a marshalling syntax for RPC? It's slower, bulkier, and just a bad choice in comparison to a binary marshalling mechanism. Now as a syntax for an RPC's IDL XML makes a lot of sense, but not as a transport.
Glad to get that off my chest. I have a bitter history with XML. I was the first person at my former company to bring XML in as a uniform configuration file format for our product, but then found myself a couple of years later forced into adding XML specific features to the filesystem that was the core of our company's product. I spent a week thinking about the idea, and concluded that it was a bad one. Thus followed a long (and fruitless) battle with management to scratch the plan. The end result was a technically nifty but useless set of features. The work remains unreleased for lack of customer interest. At least I get a bit of "I told you so." pleasure.
In my years in the commercial software development world--admittedly 2 companies, both startups--we've never considered outsourcing any work overseas. We did outsource I18N work--to an American company--because not one of us programmers wanted to touch I18N. The universal experience of all the programmers I know in the USA is that outsourcing _significant_ software development overseas results in universally disastrous code. It's may sound harsh but the US still has 90% of the really good coders, and any US company that wants to succeed is best advised to stick with US operations. Of course of the really good coders in the US a significant fraction are not originally American. But, I don't see the balance of talent changing any time soon.
Work your way through all the Nobel prize winners and count the number who were not married when they were doing their nobel prize winning works. I work at Stanford Medical School. The two prizewinners I was familiar with, both in the biochemistry department, were Arthur Kornberg, and Paul Berg. Both of whom were married well before their nobel prize winning work. Let's add (and I may get a few wrong) Richard Feynmann, Pierre and Marie Curie, Niehls Bohr, Robert B. Woodward. Go to the official nobel site and read the biographies of the winners. Most were married.
that make sense in a commercial environment is the good enough principle. What constitutes good enough is what calls for good judgement. If you're writing a server app that is expected to be mission critical, good enough is very good. If you're writing a one off desktop app, good enough can be quite sloppy. IMHO
In these examples I'd say the only defects are missing asserts(); An assert would document the invariant of the particular pointers' never being NULL.
Why not put the onus of mail delivery on E-mail clients and reserve SMTP servers for mail reception only? SMTP relaying is convenient, because of retries etc, but not essential. That functionality wouldn't be too difficult to incorporate into existing E-mail clients. Heck, even MS could probably manage to add such features to Outlook;) I'm probably missing something obvious that would make this untenable. Just remember there are no stupid questions only stupid people.
I'm sure SCO has some useful IP which the world would be better for if GPL'd. It's otherwise a pretty purposeless company.
First of all if you're paying $20 dollars an album you're paying too much. Try $10 - $16. You also must be very young. I started buying albums when I was 12 and am now 40. I have about 500 albums vinyl and about 300 CDs, and have never been rich. Time makes up for a lot of things.
As soon as there is a better search service than Google, Google will have problems. However, to do that a company needs to be more clever than Google. I think that will be a hard job. A trivial example of the Google folk's cleverness is the "ticker symbol", "I feel lucky" trick. Go ahead try it on "IWOV" (I used to work there).
Wouldn't it just kinda fall with you?
If you do test-first development [c2.com] and continuous integration [c2.com] (backed up with good black-box integration testing), then the number of bugs you get should be low. In my experience, that's circa one shipped bug per man-month.
In theory methodologies like this are good. In practice (at least in a startup environment) developers simply don't have time to follow such practice. Yes, you have time to write unit tests for certain complex and central objects but not for everything. You also have time to write (for servers) stress and functionality test clients. In general you just have to rely on smart programmers and frequent code reviews.
I come not to bash digital. I have a 5700 and love it. It's wonderful for color work and for most practical purposes is just as good as film. However if one is a serious photographer working in black and white, digital doesn't quite cut it, but not for reasons of resolution (though I don't think anyone's manufacturing a camera with the resolution of Tech-Pan on 4x5 ;) or dynamic range but because there is no output medium (that I know of) that can produce the beauty, resolution, dynamic range of a silver (or platinum/palladium) print. Perhaps in the future there will be service angencies who will print b&w from digital originals, but the market for such a service is so small ...