Don't lump specs/design documentation and user documentation together. They are completely different.
The design documentation should complement the code and give a new guy the high-level overview he needs to know where to start reading the code. Less documentation is good in exactly the same way that less code is good. This is about maintainability.
The user documentation is like the functionality of the code once it's running. More documentation is good in exactly the same way that more functionality is good. This is about usability.
Don't misunderstand me, I'm not saying that smaller code is always better or that more features are always better. It's the difference in considerations that separate the two types of documentation.
I also believe it squeezes the most out of developers (for better or worse). The pressure is on all the time instead of just at the end of the project and I get the impression that pair-programming drains your energy quicker than working on your own because you spend more time being focussed.
I can't tell if your claim is about agile methodologies or not, but in case it is:
The agile methodologies pick the requirements that are most solid and independent to implement first and only refine and implement the others later.
The hope is that the latter set of requirements will be easier to nail down by the time you need them. If they were to change between the start of the project and the time you needed them again, that change would not have cost you anything.
What they do not do is encourage you to make things overly generic in order to already capture future requirements.
So they do intend to reduce the cost of late changes, but not by spending more up-front.
And the fact that even their menubars have menubars. On a single screen there must be 5 or 6 places where you have some kind of menu.
Oh and what about the fact that there are menu items for options, for settings and for preferences, as well as options, settings and preferences that are not located under the options, settings and preferences menu items.
There's a limit to how much error handling code makes sense.
If you want to handle every eventuality gracefully, your code will be much more complex because of all of the error handling paths.
This will in turn increase the chance of introducing bugs caused by limited understanding of the code (most likely by others or by you a long time from now).
In my opinion there's a balance to be struck and I usually stop at the file or component boundary. If it comes from the outside, deal with it. Internally (e.g. static functions), use asserts to check if you messed up.
The article calls it "a (...) partnership to develop EUV". That's not just product development.
5 years is not a long time at all if you include the research period (and I don't mean general research in the area, but focused research/feasibility studies).
Just make sure that you allow users to add replies/comments to cases and to reopen them if they have not been satisfactorily resolved.
If the system does not allow this then only half-solving the problems is rewarded by metrics showing lower response times and a higher number of solved problems.
My experience with the help desk at work leads me to believe people will abuse this.
Re:Allow me to make a bold claim
on
Clean Code
·
· Score: 1
No, if it can be made dynamic it was trivial parallel code to begin with.
And note that I'm not saying that all code (e.g. analysis) was trivial, just the code to make the threads communicate.
Allow me to make a bold claim
on
Clean Code
·
· Score: 1
Any code where the number of threads is not determined by the design is trivial parallel code.
No, even with source code to the entire stack you will still need a, probably untrusted, prebuilt compiler to compile the compiler.
Now to be able to use an untrusted prebuilt compiler to get to a more or less trusted compiler, I'd suggest something like the following.
Get a bunch of compilers, have them all compile gcc and then have all of those gcc's compile gcc again and check if the resulting binary is identical. The trust in that last gcc depends on the chances of all those prebuilt compilers rigging the code they build in exactly the same way.
In reality it's probably a bit more involved because of the other dependencies like libc, but you get the idea.
The advantage of this approach is that the fancy stuff runs in a separate process and doesn't take down the whole browser in case of bug or memory leak
Yeah, that's been working really well so far. I'd say at least 90% of the time that Firefox 2 crashed on me was when it was using mplayerplug-in.
I guess somebody screwed up somewhere (not mplayer in this case).
I run Vista Business x64 and it's far more stable than XP. What's with the "I run <new windows version> and it's much more stable than <old windows version>" comments that keep popping up right after each release? What are the odds the person claiming this can actually back it up after just one year of running it? It would be nice if it was accompanied by a statement such as "I run Vista on a hundred machines that have been running stress tests continuously for the last year" or similar. Or maybe "I just use it on my desktop, which I boot up in the afternoon and shutdown at night", just to let us know he/she is full of shit.
I once made a program that simulated evolution of a population of creatures going after food placed randomly on the screen. The 'DNA' determined the direction they were likely to move in relative to the food as well as size of the step they took in that direction.
I expected the creatures to evolve to a 100% chance of moving in the direction of the food, but it turned out that that chance settled at about 75%. Even if I gave half of the initial set of creatures a 100% preference of going towards the food, it would still be evolved out (ruling out a local maximum at 75%). Interestingly most of the remaining 25% ended up in the "to the left when facing the food" direction. This led me to conclude that the random generator was the cause of this (something like the next food likely to appear to the left of the current one).
Those developing in their spare time because it's fun
I work on OSS in my spare time and padding my CV is definitely not my motivation.
The article also said something about a recession making people reconsider if working for free was still a good idea.
For the above group of people, that's totally irrelevant.
Slashdot Mirror
What about the "lose a sale" part? What sales?
What am I missing?
Don't lump specs/design documentation and user documentation together. They are completely different.
The design documentation should complement the code and give a new guy the high-level overview he needs to know where to start reading the code. Less documentation is good in exactly the same way that less code is good. This is about maintainability.
The user documentation is like the functionality of the code once it's running. More documentation is good in exactly the same way that more functionality is good. This is about usability.
Don't misunderstand me, I'm not saying that smaller code is always better or that more features are always better. It's the difference in considerations that separate the two types of documentation.
I also believe it squeezes the most out of developers (for better or worse). The pressure is on all the time instead of just at the end of the project and I get the impression that pair-programming drains your energy quicker than working on your own because you spend more time being focussed.
I can't tell if your claim is about agile methodologies or not, but in case it is:
The agile methodologies pick the requirements that are most solid and independent to implement first and only refine and implement the others later.
The hope is that the latter set of requirements will be easier to nail down by the time you need them. If they were to change between the start of the project and the time you needed them again, that change would not have cost you anything.
What they do not do is encourage you to make things overly generic in order to already capture future requirements.
So they do intend to reduce the cost of late changes, but not by spending more up-front.
And the fact that even their menubars have menubars. On a single screen there must be 5 or 6 places where you have some kind of menu.
Oh and what about the fact that there are menu items for options, for settings and for preferences, as well as options, settings and preferences that are not located under the options, settings and preferences menu items.
There's a limit to how much error handling code makes sense.
If you want to handle every eventuality gracefully, your code will be much more complex because of all of the error handling paths. This will in turn increase the chance of introducing bugs caused by limited understanding of the code (most likely by others or by you a long time from now).
In my opinion there's a balance to be struck and I usually stop at the file or component boundary. If it comes from the outside, deal with it. Internally (e.g. static functions), use asserts to check if you messed up.
Oh, I guess you just write your code once and nobody will ever modify it?
Asserts should stay in there just in case you or anyone else decides to break any of the invariants in the future.
How about this one then, from 1991: http://www.imdb.com/title/tt0103239/
The article calls it "a (...) partnership to develop EUV". That's not just product development.
5 years is not a long time at all if you include the research period (and I don't mean general research in the area, but focused research/feasibility studies).
is full of shit.
I use scroll lock when I see something unexpected during the boot process and want to have some more time to read it before it scrolls off the screen.
Its vim emulation is not complete and consequently pretty annoying.
Just make sure that you allow users to add replies/comments to cases and to reopen them if they have not been satisfactorily resolved.
If the system does not allow this then only half-solving the problems is rewarded by metrics showing lower response times and a higher number of solved problems.
My experience with the help desk at work leads me to believe people will abuse this.
No, if it can be made dynamic it was trivial parallel code to begin with.
And note that I'm not saying that all code (e.g. analysis) was trivial, just the code to make the threads communicate.
Any code where the number of threads is not determined by the design is trivial parallel code.
Dude, these games are 10 years old!
Bush: Gimme the good news first.
Scientist: We found life on Mars.
Bush: So what's the bad news?
Scientist: We killed it in the TEGA.
No, even with source code to the entire stack you will still need a, probably untrusted, prebuilt compiler to compile the compiler.
Now to be able to use an untrusted prebuilt compiler to get to a more or less trusted compiler, I'd suggest something like the following.
Get a bunch of compilers, have them all compile gcc and then have all of those gcc's compile gcc again and check if the resulting binary is identical. The trust in that last gcc depends on the chances of all those prebuilt compilers rigging the code they build in exactly the same way.
In reality it's probably a bit more involved because of the other dependencies like libc, but you get the idea.
- Mplayer plug-in ...
The advantage of this approach is that the fancy stuff runs in a separate process and doesn't take down the whole browser in case of bug or memory leak
Yeah, that's been working really well so far. I'd say at least 90% of the time that Firefox 2 crashed on me was when it was using mplayerplug-in. I guess somebody screwed up somewhere (not mplayer in this case).
Exactly.
I once made a program that simulated evolution of a population of creatures going after food placed randomly on the screen.
The 'DNA' determined the direction they were likely to move in relative to the food as well as size of the step they took in that direction.
I expected the creatures to evolve to a 100% chance of moving in the direction of the food, but it turned out that that chance settled at about 75%.
Even if I gave half of the initial set of creatures a 100% preference of going towards the food, it would still be evolved out (ruling out a local maximum at 75%).
Interestingly most of the remaining 25% ended up in the "to the left when facing the food" direction. This led me to conclude that the random generator
was the cause of this (something like the next food likely to appear to the left of the current one).
- Those developing in their spare time because it's fun
I work on OSS in my spare time and padding my CV is definitely not my motivation. The article also said something about a recession making people reconsider if working for free was still a good idea. For the above group of people, that's totally irrelevant.The Philips displays released last year October have 9 views and those are used to create 3D as explained here: http://www.business-sites.philips.com/3dsolutions/ 3dtechnology/multiviewlenticulardisplay/index.html
Forget that! What sort of programmer would make a virus in a language that forces comments to be part of your executable?