The amazing thing about the 30 millisecond advantage graphic is that has been on the NYT site since July, 24, 2009, depicting 30 milliseconds as being 0.3 seconds.
Stupid management does stupid things. Smart management does smart things. Try to work for smart management. I did a project once where I slashed the size of the code base by 50% while adding features and getting rid of some annoying bugs. I was praised for my "negative productivity" because my management understood.
Metrics and automated analysis are a great tool for looking at what you've done. They aren't a good measure of developer performance by themselves.
Yet he's perfectly willing to give in to the same requirements in order to fly in a plane. I guess pragmatism wins over principle at some level of inconvenience.
Before criticizing the minister too harshly, you might want to consider that the linked blog is quotes the results of Google translate on the actual press release in Italian. It's just possible that the results of google translate are a little inaccurate.
Excellent reporting. The citizen reporter is doing a great job today.
Code review is purposefully a politically loaded process which enables management to divide and conquer and keep wages down.
Perhaps there is another thing, also called a "code review", that is different from the dysfunctional mess you appear to have experienced. I've worked in organizations that did code reviews right. They were peer reviews, conducted professionally and without ego. It was no triumph to find a defect in someone else's code and no defeat to have one found in yours. We reviewed for real issues, not compliance with standards on indentation (which can be done by a program) or naming (though we would comment on names that didn't communicate well). Metrics were recorded and reported in aggregate; they were not used to try to find "bad" team members.
We found real design flaws. On one project, design reviews caught a major global timing issue that could have resulted in a patient's heart stopping and no alarm sounding at the nurses' station. The fix was easy given we found the problem early, but would have been much harder if discovered later in testing, or disastrous if discovered in the field.
We all learned from code reviews. We gained shared knowledge of the code base - on one project we had enough shared knowledge that the death of a team member didn't derail the project completely.
It's sad that these two very different things share the name "code review", but such is life.
This guy has actually built an 8-bit CPU. Fuck, I'd be impressed if he'd built a 4-bit processor, but this is pretty damned cool.
Been there done that. Standard undergrad project in a semester course introducing computer design in 1982. I took it in a compressed summer sessions over 5 weeks. We designed a four bit computer from scratch, built it, and wrote some programs for it. My group designed an eight bit CPU, too, but we didn't have time to breadboard; we wrote an 8 bit math library for the four bit CPU instead.
I fail to see what is so impressive about this accomplishment.
How else are we supposed to play Angry birds while simultaneously listening to music downloading apps and filming in HD ? I can't wait to have to charge my phone every 4 hours !
If you can't format a floppy drive while performing other tasks, it's not real multitasking.
It would assume you have that first part, a very detailed list of everything you need, up front, before implementation.
There's the source of your misunderstanding about TDD. TDD assumes you have a test before you develop, not all of them. I had this problem with a manager with a waterfall background once. She kept asking when the tests would be "done" and I kept telling her "when we release" (okay, a little before release, but not much). When I do TDD the alternation between test writing and code writing is very high frequency - generally multiple times per day or even hour. I start with working code. I have a need to implement a feature (or fix a bug). I write a test. I write code to make the test work. Rinse. Repeat.
The tests driving the design don't have to be unit tests. I've developed TDD using acceptance tests as the driver. I've even (gasp!) used manual tests as the driver. I've even thrown out huge chunks of tests when plans changed, though more often I find that the base of tests helps me deal with the change rather than hindering me as some seem to fear.
Personally, I find TDD gets me to writing code that has fewer bugs (this part I've measured on some projects) and is easier to change (this is totally subjective) than the other approaches I've used, which have ranged from traditional waterfall (design everything in advance before coding) to just writing code as fast as I could spew it from my brain to the keyboard.
My gut is that TDD is short-term slower than just producing code as fast as I can think, but long-term pays back in maintainability. The challenge is figuring out when the net benefit goes positive. I actually used TDD for a "one off" recently (because I was rusty in the language and wanted to refresh my skills) and later found an opportunity to use the code again with slight modifications thanks to having the tests; that's more a benefit of the T rather than the whole TDD though.
Never mind the fact that they have a KID'S GAME that includes paying for virtual nothingness.
I've actually found the in-app purchases to be excellent for educating my 7 year old about informed buying decisions. He recently said "I could buy pearls in Fishies, but it would be a waste of money."
To put the AMD price rise into a slightly longer term perspective: If I had stayed at AMD (rather than leaving and dealing with my son's cancer which turned out to be way more fun than working at AMD), the options I got in 2004 would still be underwater.
That's assuming no meeting-hungry managers or aspiring politicians were in the aforementioned group. If that happened, we'd end up stuck in endless meetings
Don't worry, we'll them all away in a B-Ark. The Golgafrinchans dumped them on us, we'll make them somebody else's problem.
"I have a bomb, open the cockpit or I push the button"
I mean, honestly, even if you're a complete pacifist with absolutely zero imagination, you should still be able to answer your own damn question.
I think the passengers of flight 93 might disagree with you. Forget imagination, let's look at what real airline passengers did when faced with terrorists threatening death and destruction.
This is the nature of benchmarks... whenever people start caring about them enough, software/hardware designers optimize for the benchmark.
It is possible to work really hard to improve the benchmarks, while still being ethical and working to help the customer.
Way back when I worked at Hewlett-Packard (which I left in the early 90s), I was next to the PA-RISC compiler lab.
One day, a sign went up announcing a celebration that they'd gotten the inner loop of a certain benchmark down to 18 instructions.
They hadn't done it with hand optimization and rewriting the compiler to recognize the benchmark.
They had done it by researching and implementing a series of general purpose optimizations and measuring how they impacted the various benchmarks and real code. As I recall, this particular benchmark was using some LINPACK (or maybe BLAS) code so the results were generally useful to real customers.
You were fired because of incompetent idiots in management and possibly on the technical team as well.
Nothing about Agile says "make programmers do things they haven't the skills to do".
Nothing about Agile says "don't help fellow programmers". Nothing about Agile says "let programmers fail".
Not all agile methods agree, but Extreme Programming, for example, would have had you pairing with someone who knew Java better than you did.
The Agile Manifesto says:
Through this work we have come to value:
Individuals and interactions over processes and tools
I think your former employer showed a value of process over individuals and interactions. Any good team would have had people helping you out.
I've managed or worked as a developer on several projects where we were "Agile":
One where I was lead architect and pushed Agile with the team, one by one. The project ultimately failed, but the team made more progress in six months than they'd made in the previous two years.
One started as a management push with the guy assigned to promote it starting his pitch "I don't really believe in this, but...." (really, he had a slide with those words on it).
It was used as an excuse for cowboy coding. We did "eXtreme Programming" - with no tests, no stories, and no pairing. Miserable failure.
Ran a startup with Agile (XP) all the way and a team committed to it. We built exactly what our customer (marketing) wanted and nobody wanted to buy it.
Was brought in to save a flailing project. Used some Agile methods so we could start demonstrating incremental progress. The goal never changed, so Agile's ability to deal with changing requirements wasn't helpful. The ability to demonstrate small, concrete progress was hugely valuable. Project released on the revised schedule we targeted when I came in.
Buffed up the code enough to sell it (and the hardware it supported), which was management's goal from the beginning.
Probably could have done it without Agile, but lack of information about where we were (nobody really knew how much work was left when I got there) made Agile helpful.
Built an online system using the (then) newfangled Ruby on Rails. Customer took the "change" thing to heart so much that they were often reversing decisions made at the previous weekly meeting. We put change management into place that talked directly about what features they wouldn't get as a result of each change (really simple, just a piece of yarn on a blackboard, stories above the yarn were doable in the time/effort available, below weren't). Customer didn't take the Agile acceptance stuff seriously and would take 6-8 weeks to look at our releases (which by agreement with them were every three weeks). We managed that aggressively, added our own testing staff and delivered successfully.
Did a prototype for a web system using Agile. Requirements changed radically week to week. Prioritized aggressively and delivered minimal working code as quickly as possible.
As a result of the prototype, the client got angel funding. None of the prototype code was used for anything other than Angel demos.
What I've learned:
There is No Silver Bullet. Agile is a tool that can work on projects that hit the sweet spot. If you haven't got a clue, Agile won't help you.
If you know exactly what you're building, Agile's flexibility will be of no benefit.
If you are doing fixed price bidding, you need to be careful about the definition of "done".
The definition he (and the other sources) gave was that it is (simplifying and paraphrasing) any program that made decisions and took actions based on environmental inputs.
By this definition the firmware in the microcontroller in my thermostat is AI. Perhaps the wording was oversimplified or paraphrased incorrectly.
I've been peripherally involved in a number of news stories, both print and television. Most of the time, there has been no fact-checking follow up. I've been frequently surprised, and occasionally appalled, at how distorted the stories were. The one major exception was Sports Illustrated. My son was on the cover of the May 8, 2006, Sports Illustrated, and wound up being covered in three paragraphs of the "Next Stage" (last two paragraphs on the first page, first on the next). After Austin Murphy submitted final copy, a fact checker called me and reviewed questions for 15 minutes. During the call, she checked several things on the web at third party sources. I thought it was interesting that SI did more fact checking than (for example) the Boston Globe.
According to the fine article the case was settled. There was no trial. There was no jury. This is what the government agreed to in order to avoid a trial.
Ha... I don't *try* to avoid jury duty, but I've found that after it becomes apparent that you're not a clueless loser, whichever side is planning on trying to pull a fast one will try to get rid of you...
Last time I was called for jury duty, it was a Deceptive Trade Practices Act lawsuit against Ford for a supposedly defective truck. Several years prior, I was preparing Lemon Law and Deceptive Trade Practices Act action against a different company for an accessible van conversion that didn't work as advertised. Neither the plaintiff nor the defense saw any problem with that. After I disclosed it, the only question I got was "Was the matter resolved to your satisfaction?" to which I answered "yes" and was not asked to clarify (the other party, realizing I was about to sue them, paid me back all my costs, including expenses incurred trying to get it fixed and interest paid on the car loan, and took the vehicle back). I wound up being the odd juror out on a 5 to 1 decision (allowed here in Texas on civil matters) for the defendant. My fellow jurors bizarrely found the truck to not be defective, which let them avoid having to answer the other (5?) questions posed to us in the jury instructions. The only evidence offered about that question was the Texas Lemon Law Complaint which had found the truck to be defective and Ford was required to take it back. The decision came at 3:30 PM on Friday afternoon. The other jurors expressed a desire to get home without getting stuck in rush hour or having to come back on Monday. The other juror who was siding with me changed her vote because "they'll probably appeal it anyway."
I am currently exempt from Texas jury duty because I am the primary caregiver for a child under 10.
P.S. The judge was very clear we couldn't talk about deliberations during the trial, but were free to discuss afterwards. As far as I know, there was no appeal.
Many people do not find Dilbert at all funny [or understand why some others find it funny], having never worked in a similar office setting.
Actually, I used to find Dilbert hilariously funny when I worked in a similar environment. Then I spent 2-1/2 years consulting at one of the RBOCs, and realized Scott Adams was not actually funny - he was just reporting what literally happened at work.
Slashdot Mirror
The amazing thing about the 30 millisecond advantage graphic is that has been on the NYT site since July, 24, 2009, depicting 30 milliseconds as being 0.3 seconds.
Stupid management does stupid things. Smart management does smart things. Try to work for smart management. I did a project once where I slashed the size of the code base by 50% while adding features and getting rid of some annoying bugs. I was praised for my "negative productivity" because my management understood.
Metrics and automated analysis are a great tool for looking at what you've done. They aren't a good measure of developer performance by themselves.
How many of us would avoid long-distance trains,
Yet he's perfectly willing to give in to the same requirements in order to fly in a plane. I guess pragmatism wins over principle at some level of inconvenience.
Before criticizing the minister too harshly, you might want to consider that the linked blog is quotes the results of Google translate on the actual press release in Italian. It's just possible that the results of google translate are a little inaccurate.
Excellent reporting. The citizen reporter is doing a great job today.
Your right, but irregardless that doesn't affect my point nor does you're criticism phase me.
I think you meant "effect".
;-)
Code review is purposefully a politically loaded process which enables management to divide and conquer and keep wages down.
Perhaps there is another thing, also called a "code review", that is different from the dysfunctional mess you appear to have experienced. I've worked in organizations that did code reviews right. They were peer reviews, conducted professionally and without ego. It was no triumph to find a defect in someone else's code and no defeat to have one found in yours. We reviewed for real issues, not compliance with standards on indentation (which can be done by a program) or naming (though we would comment on names that didn't communicate well). Metrics were recorded and reported in aggregate; they were not used to try to find "bad" team members.
We found real design flaws. On one project, design reviews caught a major global timing issue that could have resulted in a patient's heart stopping and no alarm sounding at the nurses' station. The fix was easy given we found the problem early, but would have been much harder if discovered later in testing, or disastrous if discovered in the field.
We all learned from code reviews. We gained shared knowledge of the code base - on one project we had enough shared knowledge that the death of a team member didn't derail the project completely.
It's sad that these two very different things share the name "code review", but such is life.
This guy has actually built an 8-bit CPU. Fuck, I'd be impressed if he'd built a 4-bit processor, but this is pretty damned cool.
Been there done that. Standard undergrad project in a semester course introducing computer design in 1982. I took it in a compressed summer sessions over 5 weeks. We designed a four bit computer from scratch, built it, and wrote some programs for it. My group designed an eight bit CPU, too, but we didn't have time to breadboard; we wrote an 8 bit math library for the four bit CPU instead.
I fail to see what is so impressive about this accomplishment.
Actually I think "fish" might fit the bill: One fish, two fish, all the fishes in the sea
How else are we supposed to play Angry birds while simultaneously listening to music downloading apps and filming in HD ? I can't wait to have to charge my phone every 4 hours !
If you can't format a floppy drive while performing other tasks, it's not real multitasking.
Now, get off of my lawn!
It would assume you have that first part, a very detailed list of everything you need, up front, before implementation.
There's the source of your misunderstanding about TDD. TDD assumes you have a test before you develop, not all of them. I had this problem with a manager with a waterfall background once. She kept asking when the tests would be "done" and I kept telling her "when we release" (okay, a little before release, but not much). When I do TDD the alternation between test writing and code writing is very high frequency - generally multiple times per day or even hour. I start with working code. I have a need to implement a feature (or fix a bug). I write a test. I write code to make the test work. Rinse. Repeat.
The tests driving the design don't have to be unit tests. I've developed TDD using acceptance tests as the driver. I've even (gasp!) used manual tests as the driver. I've even thrown out huge chunks of tests when plans changed, though more often I find that the base of tests helps me deal with the change rather than hindering me as some seem to fear.
Personally, I find TDD gets me to writing code that has fewer bugs (this part I've measured on some projects) and is easier to change (this is totally subjective) than the other approaches I've used, which have ranged from traditional waterfall (design everything in advance before coding) to just writing code as fast as I could spew it from my brain to the keyboard.
My gut is that TDD is short-term slower than just producing code as fast as I can think, but long-term pays back in maintainability. The challenge is figuring out when the net benefit goes positive. I actually used TDD for a "one off" recently (because I was rusty in the language and wanted to refresh my skills) and later found an opportunity to use the code again with slight modifications thanks to having the tests; that's more a benefit of the T rather than the whole TDD though.
YMMV.
Never mind the fact that they have a KID'S GAME that includes paying for virtual nothingness.
I've actually found the in-app purchases to be excellent for educating my 7 year old about informed buying decisions. He recently said "I could buy pearls in Fishies, but it would be a waste of money."
To put the AMD price rise into a slightly longer term perspective: If I had stayed at AMD (rather than leaving and dealing with my son's cancer which turned out to be way more fun than working at AMD), the options I got in 2004 would still be underwater.
AMD price history
.... they would presumably deal with those humans that resist the decompiling the same way parents deal with children who won't eat their vegetables
By serving them in cheese sauce?
Yummmmm, cheeeeeese.
That's assuming no meeting-hungry managers or aspiring politicians were in the aforementioned group. If that happened, we'd end up stuck in endless meetings
Don't worry, we'll them all away in a B-Ark. The Golgafrinchans dumped them on us, we'll make them somebody else's problem.
I often build couch cushion forts in my living room
There is a difference between childlike and childish
"I have a bomb, open the cockpit or I push the button"
I mean, honestly, even if you're a complete pacifist with absolutely zero imagination, you should still be able to answer your own damn question.
I think the passengers of flight 93 might disagree with you. Forget imagination, let's look at what real airline passengers did when faced with terrorists threatening death and destruction.
being a hero is fun
After all, who doesn't want to run around work wearing a leotard with underpants on the outside?
This is the nature of benchmarks... whenever people start caring about them enough, software/hardware designers optimize for the benchmark.
It is possible to work really hard to improve the benchmarks, while still being ethical and working to help the customer. Way back when I worked at Hewlett-Packard (which I left in the early 90s), I was next to the PA-RISC compiler lab. One day, a sign went up announcing a celebration that they'd gotten the inner loop of a certain benchmark down to 18 instructions. They hadn't done it with hand optimization and rewriting the compiler to recognize the benchmark. They had done it by researching and implementing a series of general purpose optimizations and measuring how they impacted the various benchmarks and real code. As I recall, this particular benchmark was using some LINPACK (or maybe BLAS) code so the results were generally useful to real customers.
I was fired from a job because of Agile...
You were fired because of incompetent idiots in management and possibly on the technical team as well. Nothing about Agile says "make programmers do things they haven't the skills to do". Nothing about Agile says "don't help fellow programmers". Nothing about Agile says "let programmers fail". Not all agile methods agree, but Extreme Programming, for example, would have had you pairing with someone who knew Java better than you did. The Agile Manifesto says:
Through this work we have come to value: Individuals and interactions over processes and tools
I think your former employer showed a value of process over individuals and interactions. Any good team would have had people helping you out.
I've managed or worked as a developer on several projects where we were "Agile":
What I've learned:
There is No Silver Bullet. Agile is a tool that can work on projects that hit the sweet spot. If you haven't got a clue, Agile won't help you. If you know exactly what you're building, Agile's flexibility will be of no benefit. If you are doing fixed price bidding, you need to be careful about the definition of "done".
The definition he (and the other sources) gave was that it is (simplifying and paraphrasing) any program that made decisions and took actions based on environmental inputs.
By this definition the firmware in the microcontroller in my thermostat is AI. Perhaps the wording was oversimplified or paraphrased incorrectly.
I've been peripherally involved in a number of news stories, both print and television. Most of the time, there has been no fact-checking follow up. I've been frequently surprised, and occasionally appalled, at how distorted the stories were. The one major exception was Sports Illustrated. My son was on the cover of the May 8, 2006, Sports Illustrated, and wound up being covered in three paragraphs of the "Next Stage" (last two paragraphs on the first page, first on the next). After Austin Murphy submitted final copy, a fact checker called me and reviewed questions for 15 minutes. During the call, she checked several things on the web at third party sources. I thought it was interesting that SI did more fact checking than (for example) the Boston Globe.
According to the fine article the case was settled. There was no trial. There was no jury. This is what the government agreed to in order to avoid a trial.
Ha... I don't *try* to avoid jury duty, but I've found that after it becomes apparent that you're not a clueless loser, whichever side is planning on trying to pull a fast one will try to get rid of you...
Last time I was called for jury duty, it was a Deceptive Trade Practices Act lawsuit against Ford for a supposedly defective truck. Several years prior, I was preparing Lemon Law and Deceptive Trade Practices Act action against a different company for an accessible van conversion that didn't work as advertised. Neither the plaintiff nor the defense saw any problem with that. After I disclosed it, the only question I got was "Was the matter resolved to your satisfaction?" to which I answered "yes" and was not asked to clarify (the other party, realizing I was about to sue them, paid me back all my costs, including expenses incurred trying to get it fixed and interest paid on the car loan, and took the vehicle back). I wound up being the odd juror out on a 5 to 1 decision (allowed here in Texas on civil matters) for the defendant. My fellow jurors bizarrely found the truck to not be defective, which let them avoid having to answer the other (5?) questions posed to us in the jury instructions. The only evidence offered about that question was the Texas Lemon Law Complaint which had found the truck to be defective and Ford was required to take it back. The decision came at 3:30 PM on Friday afternoon. The other jurors expressed a desire to get home without getting stuck in rush hour or having to come back on Monday. The other juror who was siding with me changed her vote because "they'll probably appeal it anyway."
I am currently exempt from Texas jury duty because I am the primary caregiver for a child under 10.
P.S. The judge was very clear we couldn't talk about deliberations during the trial, but were free to discuss afterwards. As far as I know, there was no appeal.
References:
Texas Jury Size and Use
Texas Exemptions from Jury Service
Many people do not find Dilbert at all funny [or understand why some others find it funny], having never worked in a similar office setting.
Actually, I used to find Dilbert hilariously funny when I worked in a similar environment. Then I spent 2-1/2 years consulting at one of the RBOCs, and realized Scott Adams was not actually funny - he was just reporting what literally happened at work.
If this is counting Window's Users "donations" to Microsoft, McAfee ....
That reasoning doesn't cover why Mac users are donating 40% more than Windows users (per TFA).