However, after an extensive study, researches at the Fashion Dept. at John Hopkins University discovered a slight color-wheel miscalculation in their assessment of the Spring 2002 PC line. It turns out now, that Beige is the new black.
That's because he began to deviate from the pattern.
I've been on the Uberman cycle for about ~95 days now, and I feel great. I've average about 3.5 hours of sleep a day, and I realy feel as refreshed as I used to be after a 10 hour sleep-fest. I highly recommend it to anyone who is willing to ..Hccchhhh.............zZZZZZzzzzzzzzzzzzzzzzzzzzz zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
Why? Because in India, most of the most popular music is not US pop music. The most popular music comes from movie soundtracks. No, not the soundtrack The Scopion King, either. In India, movies are primarily used as a vehicle for promoting new music. Indian movies have a large number of song and dance numbers, and the plot is typically a vehicle used to tie together the diferent numbers (this is why I was really surprised to see an Indian movie up for an Oscar nod...unusual).
So, the most popular music Indians will be searching for will be Indian movie soundtracks. Still, though, this may seem like a move in the right direction, it will ultimately not prove to be worthwhile. Why? Simple. The US Dollar goes a lot further in India, thus 25 cents is not cheap over there. Besides, why pay for music when you can get it for free? Music piracy in India is EVERYWHERE. It is so bad, in fact, that it is common to be able to download (or buy) the soundtrack for a summer blockbuster movie months before it is even released! So, no one will ante up to this subscription service until all of the piracy has been virtually eliminated. ...and the piracy in India will probably be eliminated right around the same time I open up my Texas Steakhouse in New Delhi.
Many years ago, Bose produced a set of noise-cancellation headphones used for aviation purposes. They're pretty damn cool, and pretty damn expensive.
Also, about 5 years back, Lotus had actually developed technology to cancel out engine noise in the cockpit of their cars. Funny thing about that one was that, though they developed the technology, the chose not to deploy it on their vehicles as their signature tinny engine sound was something Lotus owners really liked about the cars.
In a related story, the DoJ has uncovered corporate email from top executives in Microsoft indicating that the movement of the magnetic North Pole is part of a large-scale strategic initiative to corner the navigation software industry. Bill Gates intends to migrate the Pole to Microsoft headquarters in Redmond, WA, at which point MS will claim corporate ownership of said pole.
In a follow-up story, Canadian scientists are puzzled at the problem with the North Pole moving.
"Quite honestly, eh, we are unsure what dis is all aboot", says Dr. Ock E. Puck.
"I doon't know why, but it's moving pretty fast now, eh"
Canada's government is making swift efforts to entice the pole to stay. Currently in the works are:
Tax-breaks for Tesla-enducing corporations
Affordable shielding programs
and a bill to allow for the marriage of poles of the same orientation.
Well thought out response. However, you are still missing the point. Perhaps I was not very clear.
You state that one of the problems with this approach is that it requires an estimate of the program size up front. This is not a problem, this is the intent! Before you can successfully schedule a project, you need to have an accurate understanding of the project's size and scope (i.e. overall capability). Without this, you have no idea what you are building to, where to stop, and when to stop.
You then conclude that this "...usually involves a rapid design phase to produce a set of classes...". This is not the case. In fact, if someone were to do this, it would immediately send off warning flags. The only time people should be rapid prototyping up front is if they are doing some initial pathfinding for a portion of the application that is very unfamiliar/new to them. Otherwise, I should be able to make a fairly accurate estimate without rapid prototyping, either by using metrics gathered from a previous task, or by drawing upon the knowledge base of my programmers, who have done something similar previously. (BTW, this approach has nothing to do with what language you choose, so it's really more of LOC/[capability] than LOC/[class/function/sub/etc])
I would also have to disagree with your assessment of what the goal of the design phase. The goal of the desing phase is to produce a design which is sufficient and necessary to meet the customer's expectations for the end product. Many people would view these two as being identical, but in reality, they are quite different. Let's take a look at Microsoft Word. It is considered to be a staple-food type Productivity tool, and it is robust enough to satisfy just about everyone's needs. Let's suppose Word never existed, and a group of mathematicians asked MS to produe a document editing tool. Would MS go out and make Word? No. Most likely, they would have produced something that is a little more like WordPad, but with a very beefy equation editing engine. Would the design be sound and robust, like it (most likely is) in MS Word? Probably not, but it would make the engineers happy, as it would be sufficient for their needs.
Anyway, getting back to the subject at hand. You said that the "approach" I gave precludes changes to the project size estimates. This is not the case. I discussed risk factors earlier. This is basically a cost/schedule variance which you will associate with every capability you plan to implement. Some have high risk, some will have low risk. The lower the risk, the more accurate your estimates are (pretty much anyone can give me an accurate LOC estimate for a "Hello, world" program, a low-risk capability). If I estimate a program to be 100,000 LOC in size, certain portions may vary in size, but, once all is said and done, the program will most likely be somewhere between 90K-->110K LOC. If it is far from that, then I must have made a mistake in determining the risk factor with some portion of the customer requirements.
The writer is truly missing the point regarding the purpose of measuring performance regarding lines of code. Source Lines of Code (LOC or SLOC) are used, by management, to get an understanding of the overall productivity of software engineers in general. It is not an end-all,be-all rule regarding software engineering. If you take a sampling of 100 good programmers, given clear requirements, and measure their performance, you will be able to determine the overall productivity for a single engineer on a per day/week/month/year basis. This allows managers to make some determinations regarding project planning, enhancements, changes, and yes, to some degree, the performance of engineers.
For example, if I know that my engineering group of X people are capable of contributing 1000 LOC per person per month (per man-month) to a project, then I can better estimate the cost and schedule of a new project. The project's scope is determined by detailing the customer's desires, and developing a break-down of capability. (Things such as R&D, training, and new technologies are identified and have an appropriate risk factor associated with then). A LOC estimate is associated with each capability, which consequently will produce a timeline and cost.
What the author should have really reflected upon was not how to refine the software productivity metric, but rather how to refine the application of that metric.
Slashdot Mirror
Originally, the new PC color was TURQUOISE.
However, after an extensive study, researches at the Fashion Dept. at John Hopkins University discovered a slight color-wheel miscalculation in their assessment of the Spring 2002 PC line.
It turns out now, that Beige is the new black.
That's because he began to deviate from the pattern.
..Hccchhhh.............zZZZZZzzzzzzzzzzzzzzzzzzzzz zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
I've been on the Uberman cycle for about ~95 days now, and I feel great. I've average about 3.5 hours of sleep a day, and I realy feel as refreshed as I used to be after a 10 hour sleep-fest.
I highly recommend it to anyone who is willing to
Or N*Sync/Limp Bizkit/etc...
Why? Because in India, most of the most popular music is not US pop music. The most popular music comes from movie soundtracks. No, not the soundtrack The Scopion King, either.
In India, movies are primarily used as a vehicle for promoting new music. Indian movies have a large number of song and dance numbers, and the plot is typically a vehicle used to tie together the diferent numbers (this is why I was really surprised to see an Indian movie up for an Oscar nod...unusual).
So, the most popular music Indians will be searching for will be Indian movie soundtracks. Still, though, this may seem like a move in the right direction, it will ultimately not prove to be worthwhile. Why? Simple. The US Dollar goes a lot further in India, thus 25 cents is not cheap over there. Besides, why pay for music when you can get it for free?
Music piracy in India is EVERYWHERE. It is so bad, in fact, that it is common to be able to download (or buy) the soundtrack for a summer blockbuster movie months before it is even released! So, no one will ante up to this subscription service until all of the piracy has been virtually eliminated.
...and the piracy in India will probably be eliminated right around the same time I open up my Texas Steakhouse in New Delhi.
-D
Paraphrasing:
As much as 1000 liters of Hydrogen gas may be stored in each cubic meter of rock!
Wow!
Let me see now... 1ml = 1cc
100^3 cc = 1m^3
10^6 cc = 1m^3
1L = 1000ml = 1000cc = 10^3cc
(10^6 cc/m^3)*(1L/10^3cc) = 10^3L/m^3
= 1000L/m^3
Gee, either that's some REALLY HEAVY hydrogen or som REALLY LIGHT rock!
Professor Freund said that his team had "tantalizing evidence" that as much as 1,000 litres of hydrogen may be trapped in each cubic metre of rock.
When asked what this could possibly mean, Dr. Freud said that it meant that he secretly wishes to engage in sexual relations with his mother.
of Hot Air Found inside of large, white buiding in Washington, DC.
After trying many different Peltier solutions, I became frustrated at how cumbersome they are and how painful they are to install.
Finally I came up with a water cooling solution that was easy, simple, and , best of all, completely free!
The picture isn't so good (it's a little hard to make out the details of the PC), but I'm sure everyone can do this mod too!
Many years ago, Bose produced a set of noise-cancellation headphones used for aviation purposes. They're pretty damn cool, and pretty damn expensive.
Also, about 5 years back, Lotus had actually developed technology to cancel out engine noise in the cockpit of their cars.
Funny thing about that one was that, though they developed the technology, the chose not to deploy it on their vehicles as their signature tinny engine sound was something Lotus owners really liked about the cars.
Let's protect the people from themselves!
All Your Channel Are Belong To Us
What the hell, the grammar is about the same...
"EchoStar Asks Supreme Court to Let Unlock Local Channels"
Trollbots, mod up into MeGaTRoll!
-more than meets the eye!
Last POST!
For 1 simple reason: Terms of Service (TOS) Agreements.
If someone picks up my wireless service and uses it for any length of time, there is nothing anyone can do about it.
The user would need to, at the very least, be FORCED to sign (or at least click) a TOS agreement before using the service.
I can see Johnny Cochran now:
If he did not click, you must acquit!
-D
Taking apart the phone is a violation of the DMCA. They should have the Chronicle arrested, and take them to court!
:)
Is this really news, or hasn't this been done...
before?
or before?
-D
Apparently Cartman's Trapper-Keeper has taken over the computer!
Run before it's too late!
Is that Tetsuo's computer?
Man: I'm here about your DVD's.
Female Sales Clerk: Are you here to buy some of our adult DVD's sir?
Man: No, ma'am. Agent Frank Dreben, MPAA-squad.
Female Sales Clerk: Is this some kind of bust?
Man: Why yes, it's very impressive...
In a related story, my brother has developed this unique mutation where he has the ability to use his left and right arm with equal dexterity...
Thousands of young Chinese circus performers have mutated themselves to be able to manipulate and balance large balls with their feet.
I have mutated my left arm to be able to manipulate a kyboard, while having mutated my right arm to be able to manipulate a mouse with ease.
My group of coworkers and myself have managed to mutate our brains into being able to quickly write and read computer language syntax.
Amazing!
In a related story, the DoJ has uncovered corporate email from top executives in Microsoft indicating that the movement of the magnetic North Pole is part of a large-scale strategic initiative to corner the navigation software industry.
Bill Gates intends to migrate the Pole to Microsoft headquarters in Redmond, WA, at which point MS will claim corporate ownership of said pole.
Microsoft: We'll Tell Where to Go Today.
"Quite honestly, eh, we are unsure what dis is all aboot", says Dr. Ock E. Puck.
"I doon't know why, but it's moving pretty fast now, eh"
Canada's government is making swift efforts to entice the pole to stay. Currently in the works are:
Tax-breaks for Tesla-enducing corporations
Affordable shielding programs
and a bill to allow for the marriage of poles of the same orientation.
Well thought out response. However, you are still missing the point. Perhaps I was not very clear.
You state that one of the problems with this approach is that it requires an estimate of the program size up front. This is not a problem, this is the intent! Before you can successfully schedule a project, you need to have an accurate understanding of the project's size and scope (i.e. overall capability). Without this, you have no idea what you are building to, where to stop, and when to stop.
You then conclude that this "...usually involves a rapid design phase to produce a set of classes...". This is not the case. In fact, if someone were to do this, it would immediately send off warning flags. The only time people should be rapid prototyping up front is if they are doing some initial pathfinding for a portion of the application that is very unfamiliar/new to them. Otherwise, I should be able to make a fairly accurate estimate without rapid prototyping, either by using metrics gathered from a previous task, or by drawing upon the knowledge base of my programmers, who have done something similar previously.
(BTW, this approach has nothing to do with what language you choose, so it's really more of LOC/[capability] than LOC/[class/function/sub/etc])
I would also have to disagree with your assessment of what the goal of the design phase. The goal of the desing phase is to produce a design which is sufficient and necessary to meet the customer's expectations for the end product. Many people would view these two as being identical, but in reality, they are quite different.
Let's take a look at Microsoft Word. It is considered to be a staple-food type Productivity tool, and it is robust enough to satisfy just about everyone's needs. Let's suppose Word never existed, and a group of mathematicians asked MS to produe a document editing tool. Would MS go out and make Word? No. Most likely, they would have produced something that is a little more like WordPad, but with a very beefy equation editing engine. Would the design be sound and robust, like it (most likely is) in MS Word? Probably not, but it would make the engineers happy, as it would be sufficient for their needs.
Anyway, getting back to the subject at hand. You said that the "approach" I gave precludes changes to the project size estimates. This is not the case. I discussed risk factors earlier. This is basically a cost/schedule variance which you will associate with every capability you plan to implement. Some have high risk, some will have low risk. The lower the risk, the more accurate your estimates are (pretty much anyone can give me an accurate LOC estimate for a "Hello, world" program, a low-risk capability).
If I estimate a program to be 100,000 LOC in size, certain portions may vary in size, but, once all is said and done, the program will most likely be somewhere between 90K-->110K LOC. If it is far from that, then I must have made a mistake in determining the risk factor with some portion of the customer requirements.
MS: You're cheat-in'! I'm telling!! I'm telling!
Sony: Tell you what. We'll Rochambeau you for it.
MS: What's Rochambeau?
The writer is truly missing the point regarding the purpose of measuring performance regarding lines of code.
Source Lines of Code (LOC or SLOC) are used, by management, to get an understanding of the overall productivity of software engineers in general. It is not an end-all,be-all rule regarding software engineering.
If you take a sampling of 100 good programmers, given clear requirements, and measure their performance, you will be able to determine the overall productivity for a single engineer on a per day/week/month/year basis. This allows managers to make some determinations regarding project planning, enhancements, changes, and yes, to some degree, the performance of engineers.
For example, if I know that my engineering group of X people are capable of contributing 1000 LOC per person per month (per man-month) to a project, then I can better estimate the cost and schedule of a new project. The project's scope is determined by detailing the customer's desires, and developing a break-down of capability. (Things such as R&D, training, and new technologies are identified and have an appropriate risk factor associated with then).
A LOC estimate is associated with each capability, which consequently will produce a timeline and cost.
What the author should have really reflected upon was not how to refine the software productivity metric, but rather how to refine the application of that metric.
Thank God 20th Century Fox didn't ACQUIRE the rights to the movie...