That is not the fault of the practice of commenting code. That is the fault of lazy-assed developers who don't maintain the comments.
If the practice doesn't work in reality, it is not a good practice, regardless of whose "fault" it is. Fortunately there are better ways to achieve readable and maintainable code.
The usual way comments are used is to write crappy code, and then add comments to explain it.
This is analogous to using perfume to cover a bad smell. It kinda works, but it is much better to get rid of the stench in the first place. Translated to programming, that means that you should work hard to make your actual code readable. That means good naming, but also good general design. If you can't find a good name for a class or function, that is a clear sign it should be redesigned, probably broken up.
If you do this well, there some things will still need comments, and for those you should by all means do so. But it is probably 1-5% of the typical "well commented" code base. In code like this, when you see a comment, you will actually be interested to read it!
This way you also have no need to apply the strict discipline that you talk about of always updating both the code and the comments, and there is no risk that they get out of sync. All that energy and effort you have to spend doing that can then be redirected to more productive efforts.
Tired of the "magic" straw man
on
Becoming Agile
·
· Score: 1
I don't think anyone has claimed that Agile is magic or that it can make mediocre programmers create a great project.
It's just a collection of sane and rational practices to get important work done as well as possible.
At some point in the permanent shadow behind the earth, you will see all the sunsets and sunrises on the planet at once, as a bright red ring. It should be an awesome sight, and is something no human has yet seen. The first travel operator who goes there will be able to charge a lot.
I don't know how far out you'd have to be. From the pictures it looks like the Moon is too close.
TDD made me better. Much better. The discipline of only writing code that is forced out by the tests makes you write more precise tests. The better tests in turn makes you write better code. It takes a while to get into this "upside down" way of thinking.
"The code doesn't deal with leap years yet, so I'm clearly missing a test" is a quite different mind set from "Let's throw some random dates at it and verify that my code works".
TDD is not primarily about testing, but a design method. That you end up with a full test suite when the design is done is a very fortunate byproduct, but not the main purpose. Another aspect is that by starting out as a user of the code, you end up producing better APIs. Digressions, I know.
I don't care more now than I used to, I just use a better engineering practice than I did.
Nobody said that TDD is the only way, that it transforms you to another person or that it is "some magic". That so many people read fanatical cult proclamations into the humble text I wrote was fascinating.
1) Microsoft writes method (let's say one hour again) 2) Microsoft writes test for method. Test includes random dates but not December 31st, 2008. One hour.
That is not Test Driven Development.
In TDD, you actually let the tests drive the development. You first write a test, then the simplest code that will satisfy it. Then add more tests/assertions and modify the code. Rinse and repeat until you've run out of edge cases. For a function like this, you'd probably do 3-5 iterations. Sounds like a lot, but it shouldn't take more than 10-20 minutes.
Of course there can still be bugs, but it's much less likely when every line you write is in direct response to, and is executed and verified by, a test. Actually executing the code, rather than looking at it and thinking "yeah, that looks right" gives much better results. I've done both models for years and would never go back.
Writing tests after the code is a fine practice too. It's much better (and easier) than writing no tests, but TDD is a quantum leap beyond that. It is an acquired skill though. If you're not learning it from someone who knows the techniques, it's hard to get very effective with it.
I agree that TDD works differently well for different types of problems. This kind of pure algorithmic function is where it works the best. It's so much faster and higher quality than the thinking way.
I made no claims about TDD in general in the original post, and should perhaps leave it at that. But I'd be very hesitant to bet my livelihood on any complex code that I couldn't know if it worked or not. Sure, some things can't easily be broken into testable components. Sometimes software engineering requires hard work, but it is often worth the effort.
The moon is no colder than earth, on average. But I think the problem is that water can't exist as a liquid in vacuum, regardless of temperature. This is why we're looking for water (ice) in the permanently dark craters near the poles.
I disagree: if all drugs were legal, the people currently selling them would move onto some other lucrative, illegal activity. For example, the Mafia didn't cease to exist when Prohibition ended and they couldn't run their speakeasys anymore; they just stepped up their extortion, money laundering, etc. to compensate.
So who would sell the drugs after legalization then??
I agree that to some extent today's drug dealers are in it because of the high risk/high reward aspect. But hardly all or even most of them. Also, there is not an infinite supply of lucrative and illegal activities. Once all victimless crimes have been legalized, few would be left.
When moving, you do have to report your changed address to the DMV.
In the US, the authorities know exactly where you live and many many other things, just like in Europe. The difference is that they're legally obliged to pretend that they don't, resulting in the worst of both worlds: The state knows all about you, but you still have to tell them things they already know, again and again.
Anyway, Chrome is such a radically different design than Firefox that no amount of code contributions could turn one into another. This is how it has to play out.
I've never seen any interesting and useful software that is ever "finished". You always need to add and change things, and there is always far more functionality wanted than you can produce.
If you clean up and refactor as you go, rather than at "the end", what you have described is Agile/XP development.
Slashdot Mirror
That is not the fault of the practice of commenting code. That is the fault of lazy-assed developers who don't maintain the comments.
If the practice doesn't work in reality, it is not a good practice, regardless of whose "fault" it is. Fortunately there are better ways to achieve readable and maintainable code.
The usual way comments are used is to write crappy code, and then add comments to explain it.
This is analogous to using perfume to cover a bad smell. It kinda works, but it is much better to get rid of the stench in the first place. Translated to programming, that means that you should work hard to make your actual code readable. That means good naming, but also good general design. If you can't find a good name for a class or function, that is a clear sign it should be redesigned, probably broken up.
If you do this well, there some things will still need comments, and for those you should by all means do so. But it is probably 1-5% of the typical "well commented" code base. In code like this, when you see a comment, you will actually be interested to read it!
This way you also have no need to apply the strict discipline that you talk about of always updating both the code and the comments, and there is no risk that they get out of sync. All that energy and effort you have to spend doing that can then be redirected to more productive efforts.
I don't think anyone has claimed that Agile is magic or that it can make mediocre programmers create a great project.
It's just a collection of sane and rational practices to get important work done as well as possible.
Sure, my local politicians are incompetent and corrupt.
But I see now that it could be much worse!
This is all true.
But I find it better to think about this speed of 213 Mm/s as the speed of light (electromagnetic radiation) in that material.
Parties are way more important to people's life than political rallies, and closing down the social life for a group of people is serious harassment.
Political rallies are only held for cameras these days. Real political activity happens in the media and the internet.
Hmpf!!
Pair programming is hard. If you just put two random programmers in front of a computer, they will probably not work much magic.
If you learn it from people who are good at it, it is an incredible productivity booster.
Well, even Firefly wasn't much good until 5-8 episodes in, as I recall it.
Here's a tip for future space tourism operators:
At some point in the permanent shadow behind the earth, you will see all the sunsets and sunrises on the planet at once, as a bright red ring. It should be an awesome sight, and is something no human has yet seen. The first travel operator who goes there will be able to charge a lot.
I don't know how far out you'd have to be. From the pictures it looks like the Moon is too close.
TDD made me better. Much better. The discipline of only writing code that is forced out by the tests makes you write more precise tests. The better tests in turn makes you write better code. It takes a while to get into this "upside down" way of thinking.
"The code doesn't deal with leap years yet, so I'm clearly missing a test" is a quite different mind set from "Let's throw some random dates at it and verify that my code works".
TDD is not primarily about testing, but a design method. That you end up with a full test suite when the design is done is a very fortunate byproduct, but not the main purpose. Another aspect is that by starting out as a user of the code, you end up producing better APIs. Digressions, I know.
I don't care more now than I used to, I just use a better engineering practice than I did.
Nobody said that TDD is the only way, that it transforms you to another person or that it is "some magic". That so many people read fanatical cult proclamations into the humble text I wrote was fascinating.
There is some confusion here
Now lets look at that timeline with TDD:
1) Microsoft writes method (let's say one hour again)
2) Microsoft writes test for method. Test includes random dates but not December 31st, 2008. One hour.
That is not Test Driven Development.
In TDD, you actually let the tests drive the development. You first write a test, then the simplest code that will satisfy it. Then add more tests/assertions and modify the code. Rinse and repeat until you've run out of edge cases. For a function like this, you'd probably do 3-5 iterations. Sounds like a lot, but it shouldn't take more than 10-20 minutes.
Of course there can still be bugs, but it's much less likely when every line you write is in direct response to, and is executed and verified by, a test. Actually executing the code, rather than looking at it and thinking "yeah, that looks right" gives much better results. I've done both models for years and would never go back.
Writing tests after the code is a fine practice too. It's much better (and easier) than writing no tests, but TDD is a quantum leap beyond that. It is an acquired skill though. If you're not learning it from someone who knows the techniques, it's hard to get very effective with it.
I agree that TDD works differently well for different types of problems. This kind of pure algorithmic function is where it works the best. It's so much faster and higher quality than the thinking way.
I made no claims about TDD in general in the original post, and should perhaps leave it at that. But I'd be very hesitant to bet my livelihood on any complex code that I couldn't know if it worked or not. Sure, some things can't easily be broken into testable components. Sometimes software engineering requires hard work, but it is often worth the effort.
This kind of bug is where TDD shines. If you don't write any code unless you have a test that forces you to, it's very hard to produce this bug type.
(TDD = Test Driven Development)
The moon is no colder than earth, on average. But I think the problem is that water can't exist as a liquid in vacuum, regardless of temperature. This is why we're looking for water (ice) in the permanently dark craters near the poles.
I disagree: if all drugs were legal, the people currently selling them would move onto some other lucrative, illegal activity. For example, the Mafia didn't cease to exist when Prohibition ended and they couldn't run their speakeasys anymore; they just stepped up their extortion, money laundering, etc. to compensate.
So who would sell the drugs after legalization then??
I agree that to some extent today's drug dealers are in it because of the high risk/high reward aspect. But hardly all or even most of them. Also, there is not an infinite supply of lucrative and illegal activities. Once all victimless crimes have been legalized, few would be left.
This is a nice tale, but it's not true.
When moving, you do have to report your changed address to the DMV.
In the US, the authorities know exactly where you live and many many other things, just like in Europe. The difference is that they're legally obliged to pretend that they don't, resulting in the worst of both worlds: The state knows all about you, but you still have to tell them things they already know, again and again.
Google is the main contributor to Firefox.
Moneywise, that is. Not so much for the code.
Anyway, Chrome is such a radically different design than Firefox that no amount of code contributions could turn one into another. This is how it has to play out.
> Call me paranoid
You're paranoid, dude!
It took since 1974!
It's called "dumping" when it's done by someone you dislike, and "loss leader" otherwise.
For the politically unconnected company, there are three pricing models, all predatory:
Lower than competitors - Dumping
Higher than competitors - Ripping off consumers
The same as competitors - Price fixing
It's called "dumping" when it's done by someone you dislike, and "loss leader" otherwise.
For the politically unconnected company, there are three pricing models, all predatory:
Dumping - lower than competitors
Ripping off consumers - higher than competitors
Cartel - the same as competitors
The fact that you say this on a US web site is problematic for your credibility.
In that case Jobs has a pretty massive constipation. I hope he finds relief in some way.
I've never seen any interesting and useful software that is ever "finished". You always need to add and change things, and there is always far more functionality wanted than you can produce.
If you clean up and refactor as you go, rather than at "the end", what you have described is Agile/XP development.
"Run Google App Engine Apps On Amazon's Cloud"
Not only would this sentence have been incomprehensible 10 years ago, but almost every single word in it would have been as well!
These aren't boring times, people.