I was surprised that the courts weighed in on what is a "video game" - (excerpt from Magnavox Odyssey):
In 1985, Nintendo sued Magnavox and tried to invalidate Baer's patents by saying that the first video game was Higinbotham's Tennis For Two game built in 1958. The court ruled that this game did not use video signals and could not qualify as a video game. As a result, Nintendo lost the suit and continued paying royalties to Sanders Associates.
"Tennis for Two... did not use video signals" - wtf? TV vs CRT? I'm surprised that made a difference.
Linux...can take advantage of mainframe qualities of service, especially their reliability and security features, to support continuous business operations. For example, transparent use of redundant processor execution steps and integrity checking. Many industries, including financial services, need this unique capability for their Linux applications.
Also, mainframes support "hot" processor replacement. Linux and its applications continue to run, undisturbed, while adding or replacing processors, allowing business-friendly scaling according to demand.
So while I don't do the mainframe thing myself, it is a pleasant surprise to see Linux getting around.
BMW Bring Money in Wheelbarrows BFD Binary File Descriptor for the binutils in the GNU project. When Cygnus Support proposed developing the library, Richard Stallman said (correctly) that it would be hard; David's response was "BFD". This became the library name and "Binary File Descriptor" was invented later as the meaning of the letters. (possibly from Big Fucking Deal) WIKI The word "wiki", from the Hawaiian word meaning "quick".[7] Since its application to consumer generated media, some have suggested that "wiki" means "What I Know Is".[8]
The ebook has not died because it is a Really Good Idea.
Donald Norman observed it takes about 6 attempts for new technologies to materialize in a form that the market accepts ("The Design of Every Day Things" ). This is simply because good design is hard.
As for the many versions of ebook-readers running around the market lately, I would suggest that 1) the LCD version's don't count (non-starter as a paper replacement), and 2) there have only been two or three iterations of eInk models (e.g. numerous models from various companies, but few generations overall).
Once e-ink resolution has about doubled, I'll be moving my reading from paper to bits.
The other posts about reading entire series (aka Diskworld), or textbooks, or technical books are valid and sound. Just lately, I was intrigued by a title in another article ("The Killing Star" as mentioned here in Does Active SETI Put Earth in Danger?) and I have been unable to find one of thse "Ohhh-paper-is-the-ultimate! versions at all (or at least any price point I would pay for - the last one on Amazon I saw was a used copy for about $200 (Yeah, I wish I was kidding too.))).
Anyway...
Paper books will join pay-phones in the Obsolescence Hall Of Fame; of this I am sure.
This is *hugely* interesting. This looks at the economics of how "space garbage collectors" might be managed.
"Planetes" is an outstanding anime - *very* well thought out for the medium-term future of space development. It has a richly envisioned, deeply layered world w/Power struggles (political, corporate), collapse of petroleum economy, widening divide between 1st & 3rd world economies. It is a Very well crafted series; a rich tapestry woven of thought provoking ideas.
The gui "interface" they designed for the space suits is reason enough to watch it. It is Frickin' Cool!
The story line is Exceptionally well done, too. (Oh yeah, first rate animation is a bonus; nice to see, too.)
"Being homeless, I need five things: a job, marijuana, money, beer, and food."
If you have the others, why do you need a job?
mod error informative: about 20 years wrong
on
The Art of SQL
·
· Score: 1
"umm... dude? SQL has been around since the mid 50's." ?
Why did the parent post rate informative?
"A guy at ibm," you say:-)
The theory came out in 1970, so you're off by 15 years. Off 20 years for an actual implementation (mid 70's). Off 25 years for commercial product (79). http://en.wikipedia.org/wiki/SQL#History
----
"anchronistic and irreperably flawed." ?
"Duuuude!":-) What would you replace it with?
By ANY measure, relational databases are a RESOUNDING success. They're as much a part of the computer world as operating systems, networking, and compilers.
Yeah, 1987 is old, but I wanted a cookie example unrelated to "non-obvious inventions" about persisting web-browser session state.
United States Patent: 4,664,921
Seiden, May 12, 1987
"Dual-textured cookie products containing narrow melting range shortenings"
BACKGROUND OF THE INVENTION
"Traditionally, fresh homebaked cookes have exhibited a slightly crisp outer surface texture and a chewy, more ductile interior, while commercially prepared cookies have exhibited only a single texture, in most cases relatively hard and crisp. A recent development in the cookie industry is a storage-stable, crumb continuous dual texture cookie which closely approximates homemade yet does not deteriorate when stored in a warehouse or on a store shelf for reasonable periods of time.
Abstract
"This invention comprises crumb-continuous cookie products having distributed therein discrete regions of storage-stable crisp texture and discrete regions of storage-stable chewy texture in which the crisp regions contain a shortening having an SCl at 21.degree. C. of from about 14.0 to about 20.0 and an SCl at 33.degree. C. of from about 0.0 to about 8.0 and the chewy regions contain a shortening having an SCl at 21.degree. C. of from about 12.0 to about 18.0 and an SCl at 33.degree. C. of below about 2.0. The shortening system having these melting characteristics provides a more tender crumb texture, more desirable mouthmelt and dissipation and better flavor display in the cookie."
Recipe Excerpt
"The use of beta prime stable shortening for cookies, while not essential to the production of an acceptable cookie, is greatly preferred. If a shortening which is unstable in the beta prime form, for example, partially hydrogenated Canola oil, is used, the initially small beta prime crystals will gradually transform into large and higher melting agglomerates of beta crystals. The high melting large and grainy beta crystals detrimentally affect the taste and mouthmelt of the cookie. To produce cookies with good mouthmelt and dissipation and flavor display that will retain these characteristics under adverse storage conditions, it is greatly preferred that the solid glycerides present remain predominantly in the beta-prime form."
It's like being a flea living in a world that consists of threads woven together. On your scale, can't be sure whether it's a one-dimensional piece of yarn, a two-dimensional piece of fabric, or a three-dimensional wad of wool.
That is an artfully crafted expression.
It reminded me of
this
Here is an example of some Pretty Evil Shit: I want to laugh when I read it. Some of it is funny. Some of it is just scary. The human mind can be a freakishly messed up thing. http://mindprod.com/unmaindocumentation.html It is part of a larger essay about writting crappy code. Anybody that even comes close to software development should check it out.
--- begin excerpts --- Avoid Documenting the "Obvious" :: If, for example, you were writing an airline reservation system, make sure there are at least 25 places in the code that need to be modified if you were to add another airline. Never document where they are. People who come after you have no business modifying your code without thoroughly understanding every line of it.
Units of Measure :: Never document the units of measure of any variable, input, output or parameter. e.g. feet, metres, cartons. This is not so important in bean counting, but it is very important in engineering work.
As a corollary, never document the units of measure of any conversion constants, or how the values were derived.
It is mild cheating, but very effective, to salt the code with some incorrect units of measure in the comments.
If you are feeling particularly malicious, make up your own unit of measure; name it after yourself or some obscure person and never define it. If somebody challenges you, tell them you did so that you could use integer rather than floating point arithmetic.
On the Proper Use of Design Documents :: When implementing a very complicated algorithm, use the classic software engineering principles of doing a sound design before beginning coding. Write an extremely detailed design document that describes each step in a very complicated algorithm. The more detailed this document is, the better.
In fact, the design doc should break the algorithm down into a hierarchy of structured steps, described in a hierarchy of auto-numbered individual paragraphs in the document. Use headings at least 5 deep. Make sure that when you are done, you have broken the structure down so completely that there are over 500 such auto-numbered paragraphs.
For example, one paragraph might be: (this is a real example)
1.2.4.6.3.13 - Display all impacts for activity where selected
mitigations can apply (short pseudocode omitted).
then... (and this is the kicker) when you write the code, for each of these paragraphs you write a corresponding global function named:
Act1_2_4_6_3_13()
Do not document these functions. After all, that's what the
design document is for!
Since the design doc is auto-numbered, it will be extremely difficult to keep it up to date with changes in the code (because the function names, of course, are static, not auto-numbered.) This isn't a problem for you because you will not try to keep the document up to date. In fact, do everything you can to destroy all traces of the document.
Those who come after you should only be able to find one or two contradictory, early drafts of the design document hidden on some dusty shelving in the back room near the dead 286 computers. --- end excerpts ---
They're still working on artificial stupidity...
on
The Baby Bootstrap?
·
· Score: 5, Funny
excerpted from here:
Computer scientist Arthur Boran was ecstatic. A few minutes earlier, he had programmed a
basic mathematical problem into his
prototypical Akron I computer.
His request was simply, "Give me the
sum of every odd number between
zero and ten."
The computer's quick answer, 157, was
unexpected, to say the least. With growing
excitement, Boran requested an explanation
of the computer's reasoning.
The printout read as follows:
THE TERM "ODD NUMBER" IS AMBIGUOUS. I THEREFORE CHOOSE TO INTERPRET IT AS MEANING "A NUMBER THAT IS FUNNY LOOKING." USING MY AESTHETIC JUDGEMENT, I PICKED THE NUMBERS 3, 8, AND 147, ADDED THEM UP, AND GOT 157.
A few moments later there was an addendum:
I GUESS I MEANT 158.
Followed shortly thereafter by:
147 IS MORE THAN 10, ISN'T IT? SORRY.
Anyone doing conventional research would
have undoubtedly consigned the hapless
computer to the scrap heap. But for Boran,
the Akron I's response represented a
startling breakthrough in a little-known
field: artificial stupidity.
Boran is the head of NASA, the National
Artificial Stupidity Association ("Not to
be confused with those space people,"
he is quick to point out), a loosely-knit
band of computer-school dropouts currently
occupying an abandoned fraternity house
at the University of New Mexico.
I've been pretty happy w/XM satellite radio. I find that the BBC news/programming just crushes anything US-media has to offer; seems much more unbiased and, hmm... like they don't assume that their listeners are retarded. Now that they have NPR, some of that is interesting. A handful of more or less interesting talk channels. Some of it is just garbage, but enough is interesting that I'm very happy with it.
When I want just music, the range is hard to beat. It makes long distance driving much, much more tollerable.
in the long run...Re:Not all Americans get screwed
on
Offshoring IT
·
· Score: 1
"Long-term? What does that have to do with my bonus?" - AnyManager, YourCompany, Inc.
Why should the quarterly-driven MBA crowd care about the long run?
Once upon a time, somebody put the seti@home screensaver on a box that was being used as a server to host a little web app. The client started getting customer complaints about timeouts, so I made a trip to their site because nothing funky showed up on pc-anywhere.
It turned out that when the seti screen server kicked in it starved out IIS. Maybe there are settings to say "run in nice mode" and so forth, but I was less than amused at the time.
Personal hardware, fine - knock yourself out. Server hardware, not such a good idea (unless it is _your_ server hardware).
Short term: yes, probes are better, faster, cheaper.
Long term: our great grandchildren will be living on mars. Probes don't live, they're just expensive remote controls.
The dinosaurs never got around to going anywhere... what is our excuse? Or are we just going to wait for the next big thing (meteor, or whatever)?
"Sorry, but the long term survival of our species costs too much."
"Oh, bummer. Then I guess I'll just go watch reality tv."
We've been napping in cradle Earth long enough; we can't quit now that we're learning how to crawl.
"the good fight" ? You actually expend energy about where to put a space character. Why? 1) in Java, "if" is a reserved word so you'll never confuse it with a method (and neither will the compiler). 2) your colleagues May be writing lots of short methods like so:
ia();
ib();
ic();
id();
ie();
In this situation, while I can see that if() would be confusing, there are Other Things you should be trying to ''educate'' your colleagues about.
Years ago I read an intriguing Omni article that talked about Dragons and hydrogen. This is the best reference online I could find...
So long as we're here, we'll pass along the best theory we ever heard about the possibility of actual dragons, which, as we recall, was in an old copy of Omni magazine:
Dragons were creatures with hugely overdeveloped stomachs. Since stomachs produce hydrochloric acid & this acid breaks down into hydrogen gas, this meant that dragons were essentially giant gas bags.
Well, dragons couldn't just go & burp out excess gas the way we do - if the hydrogen ignited, they'd go up like the Hindenburg. So dragons ignited & burnt the gas as they vented it, in a controlled fashion, which was seen by terrified townsfolk as fire breathing.
From this also came the myth that swords plunged into a dragon melted. It's the natural reaction of metal to concentrated hydrochloric acid. It's also the reason there's so few dragon remains: The acid in the stomach at death ate the flesh up, or perhaps at death the remaining gas ignited & burned it up. In any case, dragons would have had very light, fragile bones, very light bodies, very weakly developed muscles, so, minus the gas, there just wasn't a lot to a dragon. There are very few old bird remains for the same reason, & dragons must have been even more fragile.
For these reasons also, their liking for bare, craggy cliffs. If it wasn't bare before he got there, he'd burn up everything around it, just burping normally. And since, aside from their breath (the worst cases of bad breath for all time), they had very few defenses, isolated places were important to them.
Presumably a reptile, they would be sluggish in the morning & probably heavier than air as well, having lost some hydrogen overnight. So it's likely dragons would vent some of their remaining hydrogen to warm themselves the morning & get their systems going. This could also account for their prevalence in northern Europe, which is otherwise too cold for large reptiles.
Wings would have helped circulate warmed air in those drafty caves, but otherwise would not have been large or powerful. They would not have been feathered. They would have been more like bat wings, even though bats are mammals. Dragon wings were used primarily for steering, not propulsion & were presumably adequate for a dragon's needs.
As to a dragon's liking for young virgin females, I cannot say. Since so much of what dragons were reputed to be matches the giant stomach gas bag theory, it's hard to write off virgin feasts as just another myth. It might well be that young girls had some particular odor that interested dragons, or it might be that young boys put up more of a struggle. It could be that dragons needed a lot of meat protein to keep themselves afloat & that small furry mammals (dogs, cats, etc.) were too small or the fur got in the way of digestion, and it could be that full grown humans were just too heavy to carry off. Leaving undefended small girls as a dragon's first choice at mealtime. People who are clever with physics & math could answer this question: What volume of hydrogen gas is needed to carry away a kicking & screaming 70 pound person? If this is how dragons got fed, then we presume they could generate the necessary additional hydrogen within a very few seconds, so a dragon with prey would be a very bloated affair.
You have been getting some really good advice from other people here.
You have a huge amount of existing code. How do you choose the first thing to handle?
Let your next feature show you where.
The project I'm on now is doing exactly the same thing you are contemplating.
We are letting new features drive the cleanup.
When it is time to add something else, change the existing system to make it easy to add the new piece. Maybe this means touching a substantial number of modules to tweak them to use a new helper function. Fine, you're not changing routines for the fun of it - you have a definate goal in mind. Maybe everyone needs to use a new html formatter. Maybe everyone needs to use a common databse interface. Whatever. When consolidate something, really consolidate - hunt down every thing that is like it and adapt the existing code to use your consolidated routine.
I would strongly encourage you to do it this way, because if you embark to the Great Cleanup it might be a long time (many many months) before you can put new business value on the table.
If you do it this way, it can become part of your team's culture - you should always stop to clean up code every now and then. It is an ongoing process, and it gets easier the more you do it (kind of like laundry or dishes... why wait until life is unbearable to clean up a little?).
Letting features drive your clean up does the following for you:
helps keep you focused (reduces the chance you'll get lost in the woods and wonder around forever).
cleans up areas of the system that are likely to change again soon
finds the most important code
makes it easier to change next time
make it easy for you management to have faith in you.
This last one is really important. If they get regular improvements to the system, they stop worrying/fearing what you are doing and start fighting to shield you so you can keep doing it. At least this matters in a for-profit environment. Make it easy for you manager to believe in you and you will make your jobs easier.
And scope it small - small bites, easy steps, and release often.
And buy the Fowler Refactoring book, and the DesignPatterns book wouldn't hurt... but that helps C++ and Java people cope with brittle type systems... this isn't such a problem for you in Perl. You would benefit more from the principles in the Refactoring book, even though it is in Java.
If your projects are fixed-bid,
look at the accounting numbers.
Is there rework involved?
What are support costs like?
Who pays for changes to a web site?
You can argue for proactive quality (design, testing, code reviews) if you can show it
will lower backend costs.
If your company is doing drive-by web sites
(with no value from repeat business), I don't understand how that can be improved.
Based on your post, it is hard to tell what
aspect of your projects has low quality.
Where does the pain come from?
p.s. Never burn your bridges.
It won't help you, it won't help your boss.
The software community is MUCH smaller
than it would appear, especially if you
stay in the same gegraphic area.
If law were as expressive as code, our society
might be a saner place.
Why is code expressive? I found this question was vexing, until I considered the meaning of "expression".
So what does "expression" mean? To express is to create a work that can be interpreted.
What is a "work" ? A "work" is a pattern embodied in a medium that can be perceived.
What is a "medium" ? Humankind has a long history of developing and using new mediums, including: cave walls, paper, microfilm, and more recently: electronic media.
What is "interpreted" ? To interpret is to deduce meaning by applying commonly accepted concepts and principles to a particular pattern.
Examples of interpreting:
Reading a book written in English.
Reading a book written in Japanese.
Reading highly specialized terminology, codes and phrases that require years of training, study and expertise to properly interpret: namely, law.
It is abundantly obvious that these examples, namely books and laws, are expressive things. And while a great many other things are expressive, we are focusing on computer code.
Computer code is a work, created by human hand.
Computer code exists as a pattern in a medium.
Computer code can be interpreted by a suitably skilled person, thus conveying deep and complex information.
To the casual observer, computer code looks as expressive as any legal statute - like utter nonsense. This is neither the fault of the observer, nor is it the fault of the code nor the statute. In other circumstance (such as after attending law school), any person would be able to properly read and interpret a legal statute.
Consider this: "Nee hau mah?" Is it expressive? Yes, if you are skilled in Mandarin: then you would know that it means "How are you?" If you are unskilled in Mandarin, does that make it less expressive? I think not.
Merely because some are unskilled in legal matters does not render a statute expressionless.
Merely because some are unskilled in programming does not render code expressionless.
Code is expression of a very pure form, allowing people to create works of great clarity and precision.
Slashdot Mirror
In 1985, Nintendo sued Magnavox and tried to invalidate Baer's patents by saying that the first video game was Higinbotham's Tennis For Two game built in 1958. The court ruled that this game did not use video signals and could not qualify as a video game. As a result, Nintendo lost the suit and continued paying royalties to Sanders Associates.
"Tennis for Two... did not use video signals" - wtf? TV vs CRT? I'm surprised that made a difference.
I read that as "If you want to build computing into a utility, you need large real-time systems running as self sufficiently as possible."
Odd? C'mon - your parents have been doin' it penguin-style for about 10 years now.
from Advantages in linux on mainframe wiki overiview:
Linux...can take advantage of mainframe qualities of service, especially their reliability and security features, to support continuous business operations. For example, transparent use of redundant processor execution steps and integrity checking. Many industries, including financial services, need this unique capability for their Linux applications.
Also, mainframes support "hot" processor replacement. Linux and its applications continue to run, undisturbed, while adding or replacing processors, allowing business-friendly scaling according to demand.
So while I don't do the mainframe thing myself, it is a pleasant surprise to see Linux getting around.
This list starts out slow but has some gems:
Donald Norman observed it takes about 6 attempts for new technologies to materialize in a form that the market accepts ("The Design of Every Day Things" ). This is simply because good design is hard.
As for the many versions of ebook-readers running around the market lately, I would suggest that 1) the LCD version's don't count (non-starter as a paper replacement), and 2) there have only been two or three iterations of eInk models (e.g. numerous models from various companies, but few generations overall).
Once e-ink resolution has about doubled, I'll be moving my reading from paper to bits. The other posts about reading entire series (aka Diskworld), or textbooks, or technical books are valid and sound. Just lately, I was intrigued by a title in another article ("The Killing Star" as mentioned here in Does Active SETI Put Earth in Danger? ) and I have been unable to find one of thse "Ohhh-paper-is-the-ultimate! versions at all (or at least any price point I would pay for - the last one on Amazon I saw was a used copy for about $200 (Yeah, I wish I was kidding too.))).
Anyway...
Paper books will join pay-phones in the Obsolescence Hall Of Fame; of this I am sure.
This is *hugely* interesting.
This looks at the economics of how "space garbage collectors" might be managed.
"Planetes" is an outstanding anime - *very* well thought out for the medium-term future of space development. It has a richly envisioned, deeply layered world w/Power struggles (political, corporate), collapse of petroleum economy, widening divide between 1st & 3rd world economies. It is a Very well crafted series; a rich tapestry woven of thought provoking ideas.
The gui "interface" they designed for the space suits is reason enough to watch it. It is Frickin' Cool!
The story line is Exceptionally well done, too.
(Oh yeah, first rate animation is a bonus; nice to see, too.)
"Being homeless, I need five things: a job, marijuana, money, beer, and food."
If you have the others, why do you need a job?
"umm... dude? SQL has been around since the mid 50's." ?
:-)
:-)
Why did the parent post rate informative?
"A guy at ibm," you say
The theory came out in 1970, so you're off by 15 years.
Off 20 years for an actual implementation (mid 70's).
Off 25 years for commercial product (79).
http://en.wikipedia.org/wiki/SQL#History
----
"anchronistic and irreperably flawed." ?
"Duuuude!"
What would you replace it with?
By ANY measure, relational databases are a RESOUNDING
success. They're as much a part of the computer world
as operating systems, networking, and compilers.
This looks like a recipe to me...
Now, with a more desireable mouth melt! mmmmm :-)
Yeah, 1987 is old, but I wanted a cookie example unrelated to "non-obvious inventions" about persisting web-browser session state.
United States Patent: 4,664,921
Seiden, May 12, 1987
"Dual-textured cookie products containing narrow melting range shortenings"
BACKGROUND OF THE INVENTION "Traditionally, fresh homebaked cookes have exhibited a slightly crisp outer surface texture and a chewy, more ductile interior, while commercially prepared cookies have exhibited only a single texture, in most cases relatively hard and crisp. A recent development in the cookie industry is a storage-stable, crumb continuous dual texture cookie which closely approximates homemade yet does not deteriorate when stored in a warehouse or on a store shelf for reasonable periods of time.
Abstract "This invention comprises crumb-continuous cookie products having distributed therein discrete regions of storage-stable crisp texture and discrete regions of storage-stable chewy texture in which the crisp regions contain a shortening having an SCl at 21.degree. C. of from about 14.0 to about 20.0 and an SCl at 33.degree. C. of from about 0.0 to about 8.0 and the chewy regions contain a shortening having an SCl at 21.degree. C. of from about 12.0 to about 18.0 and an SCl at 33.degree. C. of below about 2.0. The shortening system having these melting characteristics provides a more tender crumb texture, more desirable mouthmelt and dissipation and better flavor display in the cookie."
Recipe Excerpt "The use of beta prime stable shortening for cookies, while not essential to the production of an acceptable cookie, is greatly preferred. If a shortening which is unstable in the beta prime form, for example, partially hydrogenated Canola oil, is used, the initially small beta prime crystals will gradually transform into large and higher melting agglomerates of beta crystals. The high melting large and grainy beta crystals detrimentally affect the taste and mouthmelt of the cookie. To produce cookies with good mouthmelt and dissipation and flavor display that will retain these characteristics under adverse storage conditions, it is greatly preferred that the solid glycerides present remain predominantly in the beta-prime form."
It reminded me of this
I want to laugh when I read it.
Some of it is funny.
Some of it is just scary.
The human mind can be a freakishly messed up thing.
http://mindprod.com/unmaindocumentation.html
It is part of a larger essay about writting crappy code.
Anybody that even comes close to software development
should check it out.
--- begin excerpts ---
Avoid Documenting the "Obvious" :
writing an airline reservation system, make sure there are at
least 25 places in the code that need to be modified if you were
to add another airline. Never document where they are. People who
come after you have no business modifying your code without
thoroughly understanding every line of it.
Units of Measure :
variable, input, output or parameter. e.g. feet, metres, cartons.
This is not so important in bean counting, but it is very important
in engineering work.
As a corollary, never document the units of measure of any conversion
constants, or how the values were derived.
It is mild cheating, but very effective, to salt the code with some
incorrect units of measure in the comments.
If you are feeling particularly malicious, make up your own unit of
measure; name it after yourself or some obscure person and never
define it. If somebody challenges you, tell them you did so that
you could use integer rather than floating point arithmetic.
On the Proper Use of Design Documents :
complicated algorithm, use the classic software engineering principles
of doing a sound design before beginning coding. Write an extremely
detailed design document that describes each step in a very complicated
algorithm. The more detailed this document is, the better.
In fact, the design doc should break the algorithm down into a hierarchy
of structured steps, described in a hierarchy of auto-numbered individual
paragraphs in the document. Use headings at least 5 deep. Make sure that
when you are done, you have broken the structure down so completely that
there are over 500 such auto-numbered paragraphs.
For example, one paragraph might be: (this is a real example)then... (and this is the kicker) when you write the code, for each of these paragraphs
you write a corresponding global function named:Do not document these functions. After all, that's what the
design document is for!
Since the design doc is auto-numbered, it will be extremely difficult
to keep it up to date with changes in the code (because the function
names, of course, are static, not auto-numbered.) This isn't a problem
for you because you will not try to keep the document up to date.
In fact, do everything you can to destroy all traces of the document.
Those who come after you should only be able to find one or two
contradictory, early drafts of the design document hidden on some
dusty shelving in the back room near the dead 286 computers.
--- end excerpts ---
Computer scientist Arthur Boran was ecstatic.
A few minutes earlier, he had programmed a
basic mathematical problem into his
prototypical Akron I computer.
His request was simply, "Give me the
sum of every odd number between
zero and ten."
The computer's quick answer, 157, was
unexpected, to say the least. With growing
excitement, Boran requested an explanation
of the computer's reasoning.
The printout read as follows:
A few moments later there was an addendum:
Followed shortly thereafter by:
Anyone doing conventional research would
have undoubtedly consigned the hapless
computer to the scrap heap. But for Boran,
the Akron I's response represented a
startling breakthrough in a little-known
field: artificial stupidity.
Boran is the head of NASA, the National
Artificial Stupidity Association ("Not to
be confused with those space people,"
he is quick to point out), a loosely-knit
band of computer-school dropouts currently
occupying an abandoned fraternity house
at the University of New Mexico.
I've been pretty happy w/XM satellite radio.
I find that the BBC news/programming just crushes anything US-media has to offer; seems much more unbiased and, hmm... like they don't assume that their listeners are retarded.
Now that they have NPR, some of that is interesting.
A handful of more or less interesting talk channels.
Some of it is just garbage, but enough is interesting that I'm very happy with it.
When I want just music, the range is hard to beat.
It makes long distance driving much, much more tollerable.
"Long-term? What does that have to do with my bonus?" - AnyManager, YourCompany, Inc.
Why should the quarterly-driven MBA crowd care about the long run?
Once upon a time, somebody put the seti@home screensaver on a box that was being used as a server to host a little web app. The client started getting customer complaints about timeouts, so I made a trip to their site because nothing funky showed up on pc-anywhere.
It turned out that when the seti screen server kicked in it starved out IIS. Maybe there are settings to say "run in nice mode" and so forth, but I was less than amused at the time.
Personal hardware, fine - knock yourself out. Server hardware, not such a good idea (unless it is _your_ server hardware).
ook.
I've done that already, at least in my home.
I don't watch tv - the value-add is just too low.
Long term: our great grandchildren will be living on mars. Probes don't live, they're just expensive remote controls. The dinosaurs never got around to going anywhere... what is our excuse? Or are we just going to wait for the next big thing (meteor, or whatever)?
"Sorry, but the long term survival of our species costs too much."
"Oh, bummer. Then I guess I'll just go watch reality tv."
We've been napping in cradle Earth long enough; we can't quit now that we're learning how to crawl.
"the good fight" ?
You actually expend energy about where to put a space character. Why?
1) in Java, "if" is a reserved word so you'll never confuse it with a method (and neither will the compiler).
2) your colleagues May be writing lots of short methods like so:
ia();
ib();
ic();
id();
ie();
In this situation, while I can see that if() would be confusing, there are Other Things you should be trying to ''educate'' your colleagues about.
Years ago I read an intriguing Omni article that talked about Dragons and hydrogen. This is the best reference online I could find...
Excerpted from Dragon Tarot
This actually works pretty well for Pratchett's swamp dragons (Discworld) that tend to explode when they get agitated.
About over design in OO - check out YAGNI (You Ain't Gonna Need It) and other XP principles here. Or, take a look at this article, Is Design Dead?.
Let your next feature show you where.
The project I'm on now is doing exactly the same thing you are contemplating.
We are letting new features drive the cleanup. When it is time to add something else, change the existing system to make it easy to add the new piece. Maybe this means touching a substantial number of modules to tweak them to use a new helper function. Fine, you're not changing routines for the fun of it - you have a definate goal in mind. Maybe everyone needs to use a new html formatter. Maybe everyone needs to use a common databse interface. Whatever. When consolidate something, really consolidate - hunt down every thing that is like it and adapt the existing code to use your consolidated routine.
I would strongly encourage you to do it this way, because if you embark to the Great Cleanup it might be a long time (many many months) before you can put new business value on the table.
If you do it this way, it can become part of your team's culture - you should always stop to clean up code every now and then. It is an ongoing process, and it gets easier the more you do it (kind of like laundry or dishes... why wait until life is unbearable to clean up a little?).
Letting features drive your clean up does the following for you:
helps keep you focused (reduces the chance you'll get lost in the woods and wonder around forever).
cleans up areas of the system that are likely to change again soon
finds the most important code
makes it easier to change next time
make it easy for you management to have faith in you.
This last one is really important. If they get regular improvements to the system, they stop worrying/fearing what you are doing and start fighting to shield you so you can keep doing it. At least this matters in a for-profit environment. Make it easy for you manager to believe in you and you will make your jobs easier.
And scope it small - small bites, easy steps, and release often.
And buy the Fowler Refactoring book, and the DesignPatterns book wouldn't hurt... but that helps C++ and Java people cope with brittle type systems... this isn't such a problem for you in Perl. You would benefit more from the principles in the Refactoring book, even though it is in Java.
http://discworld.imaginary.com/DiscworldSociety/kf l.html
You can argue for proactive quality (design, testing, code reviews) if you can show it will lower backend costs. If your company is doing drive-by web sites (with no value from repeat business), I don't understand how that can be improved.
Based on your post, it is hard to tell what aspect of your projects has low quality. Where does the pain come from?
p.s. Never burn your bridges. It won't help you, it won't help your boss. The software community is MUCH smaller than it would appear, especially if you stay in the same gegraphic area.
If law were as expressive as code, our society might be a saner place.
Why is code expressive? I found this question was vexing, until I considered the meaning of "expression".
So what does "expression" mean? To express is to create a work that can be interpreted.
What is a "work" ? A "work" is a pattern embodied in a medium that can be perceived.
What is a "medium" ? Humankind has a long history of developing and using new mediums, including: cave walls, paper, microfilm, and more recently: electronic media.
What is "interpreted" ? To interpret is to deduce meaning by applying commonly accepted concepts and principles to a particular pattern.
Examples of interpreting:
It is abundantly obvious that these examples, namely books and laws, are expressive things. And while a great many other things are expressive, we are focusing on computer code.
Computer code is a work, created by human hand.
Computer code exists as a pattern in a medium.
Computer code can be interpreted by a suitably skilled person, thus conveying deep and complex information.
To the casual observer, computer code looks as expressive as any legal statute - like utter nonsense. This is neither the fault of the observer, nor is it the fault of the code nor the statute. In other circumstance (such as after attending law school), any person would be able to properly read and interpret a legal statute.
Consider this: "Nee hau mah?" Is it expressive? Yes, if you are skilled in Mandarin: then you would know that it means "How are you?" If you are unskilled in Mandarin, does that make it less expressive? I think not.
Merely because some are unskilled in legal matters does not render a statute expressionless.
Merely because some are unskilled in programming does not render code expressionless.
Code is expression of a very pure form, allowing people to create works of great clarity and precision.