That is because percent complete is a lie to make burn down charts look good. In addition, the pain of telling the truth that at 20% complete you have discovered that whatever you are working on will take twice as long is greater over a greater period of time than pretending you can complete on time until you are "95%" done, at which point, you then deal with the pain of saying you need the extra time. That way you have avoided several weeks of annoyance and negative attention from management.
This is directly related to why all estimates are inflated because management punishes people for exceeding an estimate by 10%, but does rewards people when the work is done 30% under the estimate. Add to that the tendency to fill up the estimated time even when you do overestimate, and everything ends up costing way more than it should, and every one continues pretending that those pre-project estimates are actually accurate.
My take away from SCRUM, Agile, etc... Is "Stop lying to yourself". You don't actually know how many hours it will take to complete a software project. In part, because you and your customer either can't articulate or do not really know what you want until you see it. Accept the uncertainty and deal with it. So, it is much more effective to get something functional in front of your stake holders to discover what they really want, rather than spend a bunch of time writing documents and having meetings trying to figure out what everyone wants. Even if 50% of what was developed gets thrown out, you now have 50% of the work done in likely less time than it would have taken to have all those meetings and write the documents and get approvals.
Yes, management gets into a room and overrides the key developers also and decides not to create an ordered list and instead goes back to tagging work items.
Thirded on priority is an ordered list, and anyone who says two things are equal priority should be given a clue and if they don't get a clue fired. All that needs to be done is answer one simple question. If you can only have one of these items which would it be?
Alternative less scary versions are: Which one do you want first? Which one will make the customer happiest? Which one makes more money? (Better ROI is also an option.)
True. Although, I am expressing my irritation at the fact that is such a small part of what testers end up doing because they end up spending time on testing things that would be better automated. And, if they miss it we end up with regression problems. But, once there is happiness with the UI, automation should make sure that it does not change unexpectedly, that way the tester can spend their time working on the new stuff instead of checking to make sure there was not an unexpected interaction between the old stuff and the new stuff.
The tester should not be executing automated tests either. I was probably too succinct when I said "writing automated tests" That involves deciding what the test should be, validating the test, improving based on feedback, trying other things to see if the coverage is good enough and writing the actual automated test. And, as the other reply said there is the initial test of does the interface look right, because it is hard to automate that. On the other hand once you get it right the computer can check the output and warn everyone when it changes because of an unforeseen interaction.
Which as a developer I hate. What I really want testers to do is write automated tests. The only hand test a tester should do is one to see what the automated test should do. Yes, reality ends up being a mix, but reality should be informed by the ideal. It irritates the hell out of me that testers are doing the same thing over and over, that is what computers are for.
I am a developer and I tell my testers to consider me to be evil, lazy, and malicious. They must assume I am actively trying to fool them into thinking the application is working even if it is not with the minimum amount of work possible. That generally gets them to find the defects.
Science and medical science is NOT failing us. The compound in the article was determined not to work via the scientific method, science succeeded. The pharmaceutical industry failed to develop a drug, that is not a failure of science. The pharmaceutical industry has a problem in that they are looking for blockbuster drugs. But, what is a blockbuster drug. Lately, it seems to be something that marginally increases survivability with few side effects, so they can justify prescribing it to 100,000 people at 10x the price of a generic in order to save 2 additional lives compared to the generic.
The article mentions Lipitor as the most prescribed drug. More live would be saved with the same money by prescribing cheaper generic cholesterol lowering drugs to more people because the difference in heart attacks prevented by Liptor versus the generic is a hell of a lot smaller than the price difference.
Depends on how many sounds. Music has been around for thousands of years, there a only a relatively few distinguishable notes. So, all sequences of notes shorter than a certain length must have been copied from the public domain.
A long time ago I heard about an infringement case that said something like 4 notes was a copyrightable melody. I then heard some one calculated how many unique combinations that you can get with 4 notes including various timings of the notes and what not. It was fairly small like 100,000 combinations. The thing I always thought about that is that there is 100s if not 1000s of years of public domain music. Wouldn't that make the easiest defense to such an infringement case that you actually copied a public domain work? Even better if you can find the work.
Plaintiff: You copied these 4 notes from my defendant. Defendant: No. Both your defendant and I copied those notes from this Beethoven symphony which is public domain. <play 4 notes from symphony> Judge: Case dismissed.
The real challenge would be to not identify a specific work, but convince a judge mathematically and historically that the melody in question must be public domain.
"If the design looks bollocks, please tell me and we can talk it through, it's entirely likely I screwed up" and "Whilst sobbing over your PC to 4am to solve a problem might look great on your timesheet, wtf didn't you just ask me?"
This hit home. The one I run into with developers is that if it looks like I could have done something different to make your life easier, don't just code around it. Tell me. There is a good chance I either screwed up or did it right, but can make your life easier with 5 minutes of work instead of you spending 5 hours.
Alternatively you can also stop at 50*3=150 and realize the answer must be less than 150 and only one answer was available.
I am going to be a little blunt here. Past a certain ability level of the testee, multiple choice does not test whatever the test creator intended, and instead is a contest between the test creator and the testee to see if the test creator can actually make you do the problem the test intended you to do. I usually win that game.
It probably should just say remnant. Type 1a supernova are the complete destruction of a white dwarf by nuclear fusion of a substantial portion of the white dwarf's mass, which does not leave behind a core.
Probably not a good thing, but immersive Dirty Jobs. Who would not want to have the smell of an empty sewage treatment tank in their living room while watching Mike Rowe replace the lift pump.
Yes. I did the same thing and went hmmm.... free software plus $1000 in hardware to get my 20 year old $600 guitar to play with Rock Band.... Ain't gonna happen.
Two can be fixed, one must be flexible. Cost is cost per unit time i.e. fixed number of people.
What is typical is management tries to pretend all three can be fixed. Which causes overtime and since many devs don't get paid for overtime means cost can pretend to be fixed.
Oh, and ideally the manager should have figured out how not to have it come down to late-night; but we don't live in an ideal world.
This is highly unlikely in typical development, the reason is that schedules are based on a web of falsehoods. Not lies, just things that everyone should know are false but pretend are true.
Project scope usually ends up being a falsehood, the scope changes and everyone pretends it has not and the schedule for the previous scope can still be hit. Which leads to late nights and these are typically not the fault of direct management but hte whole management structure.
Time to complete the project is usually a falsehood because estimates are made which by definition are wrong, and the schedule is set as if those estimates are fact. Is this the fault of the direct manager or the whole organization.
All of which lead to attempts to over-estimate which are bad because most of the time the project fills the time available, which means they cost more than they should.
I am sure a lot of us can think of many other things in project management that are treated as fact when in reality they are false.
One decision the manager should be making is if there is something wrong that is out of your control, perhaps the responsibility of some other development team that thinks they are done, so left on time. The manager should be there to decide whether it should be worked around, call in the manager of the other dev team to get their butt in, or call it a night and return in the morning.
Leave the devs alone and the most likely choice would probably be a work around that I expect is usually non-optimal because it is the devs ass on the line to deliver, and delivering crap that works is safer than not delivering.
That has been my experience as well, and I am by no means an expert on Agile or Scrum. I agree probably the biggest thing is the retrospective every iteration, if you don't look back at what works and what does not and are willing to change it wont work.
I also agree Scrum Master is a misnomer. I find their #1 purpose is to keep the Scrum meeting on task and short. Even removing impediments might not be their job, although making sure that some one is working on removing the impediment would be appropriate.
From what I have read, scrum methods lend themselves to the notion of disposable production teams. "Get it done, do it fast, see you later!" They want short-term hires to come in, "work some magic" and then disappear from their payroll system when they are done. They want to reduce the "overhead" of middle management and other leadership roles
Agile and Scrum don't work with the above. One of the main principles is a stable development team. If you take short term hires try to assemble them into a Scrum team, then blow that team up and start over again you are screwed. (Scrum buzzords follow) You then have to rediscover velocity every time, you have to rediscover planning poker, and you never accumulate the experience and team trust that allows one to just rely on people to know what needs to be done and to brig problems to the attention of the group and leadership when needed.
It does reduce the overhead of middle management roles in particular Project Managers who are constantly scrambling around preparing schedules that end up not fitting reality, presentation about how everything is moving according to the fake schedule, and finally shortly before code delivery telling management why the due date will not be met, and giving the next fake delivery date.
I think it works if you understand what it is and what it is not. Scrum is more about project management than coding practices. It is primarily focused on addressing the fact that the Waterfall methodology is build on information the is mostly wrong. Yet, assumes that information is right. Scrum and Agile in general is about accepting that the information is bad and dealing with it. Man-hour estimates at the beginning of a project are always wrong. Schedules at the beginning of a project are always wrong. Requirements always change from what is documented.
Now the above can and should be combined with other Agile practices like Pair programming, test driven development, continuous integration and test, etc... for the coding side. And, the thing that I would not be surprised that many organizations miss which is the retrospective. My team does two week sprints and at the end of every two weeks we have to look at what worked and what did not. And, so over time we can accumulate a process that works for us.
Bringing this around to the OPs question we have actually switched who handles the Scrum Master role a couple of times trying to figure out what would work better. And, I am not sure that we have settled on the "right" solution, yet.
Actually, the LHC creates a set of circumstances that happens all the time. It just doesn't happen if front of very sensitive particle detectors at a very high rate. So, the LHC was built to replicate events that happen all the time in front of sensitive instrumentation.
So, yes, the LHC calculations could be somewhat off, but we have observations (not calculations) of events with much higher energies than the LHC can reach with cosmic rays hitting the earth's atmosphere and we are all still here. Jupiter is much bigger, so many more of those events occur on Jupiter. The sun is even bigger and many more high energy events occur for cosmic rays hitting the sun.
The calculations for LHC safety for micro black holes come from trying to put a number on the probability that if these events can destroy a planet by creating a black hole what is the probability that the Sun, Jupiter or any other planet in the Solar System would still exist given the number of high energy LHC-like events that have occurred over the last 4.5 billion years. The probability must be incredibly small, what the LHC calculations do is put a value to incredibly small.
From a doing the best thing for the athletes I think there is something to be said for the age rule giving more athletes the opportunity to compete in the Olympics
Assuming an advantage occurs at an age between 10-14 and that it is likely a girl will grow out of that advantage through puberty it creates a very narrow window within which a gymnast may compete at an Olympic medal level. It is entirely possible that with a bad birth year a gymnast might not be good enough to make the Olympics when the Olympics occur because their 2 year peak was between Olympic years.
I think an argument can be made that the 16 year rule gives the best gymnasts a chance to compete in the Olympics at least once if not twice in their career on a level playing field with others of similar maturity. I think without that rule there is zero chance of seeing a gymnast in 2 Olympics.
Slashdot Mirror
That is because percent complete is a lie to make burn down charts look good. In addition, the pain of telling the truth that at 20% complete you have discovered that whatever you are working on will take twice as long is greater over a greater period of time than pretending you can complete on time until you are "95%" done, at which point, you then deal with the pain of saying you need the extra time. That way you have avoided several weeks of annoyance and negative attention from management.
This is directly related to why all estimates are inflated because management punishes people for exceeding an estimate by 10%, but does rewards people when the work is done 30% under the estimate. Add to that the tendency to fill up the estimated time even when you do overestimate, and everything ends up costing way more than it should, and every one continues pretending that those pre-project estimates are actually accurate.
My take away from SCRUM, Agile, etc... Is "Stop lying to yourself". You don't actually know how many hours it will take to complete a software project. In part, because you and your customer either can't articulate or do not really know what you want until you see it. Accept the uncertainty and deal with it. So, it is much more effective to get something functional in front of your stake holders to discover what they really want, rather than spend a bunch of time writing documents and having meetings trying to figure out what everyone wants. Even if 50% of what was developed gets thrown out, you now have 50% of the work done in likely less time than it would have taken to have all those meetings and write the documents and get approvals.
Yes, management gets into a room and overrides the key developers also and decides not to create an ordered list and instead goes back to tagging work items.
Thirded on priority is an ordered list, and anyone who says two things are equal priority should be given a clue and if they don't get a clue fired. All that needs to be done is answer one simple question. If you can only have one of these items which would it be?
Alternative less scary versions are:
Which one do you want first?
Which one will make the customer happiest?
Which one makes more money? (Better ROI is also an option.)
True. Although, I am expressing my irritation at the fact that is such a small part of what testers end up doing because they end up spending time on testing things that would be better automated. And, if they miss it we end up with regression problems. But, once there is happiness with the UI, automation should make sure that it does not change unexpectedly, that way the tester can spend their time working on the new stuff instead of checking to make sure there was not an unexpected interaction between the old stuff and the new stuff.
The tester should not be executing automated tests either. I was probably too succinct when I said "writing automated tests" That involves deciding what the test should be, validating the test, improving based on feedback, trying other things to see if the coverage is good enough and writing the actual automated test. And, as the other reply said there is the initial test of does the interface look right, because it is hard to automate that. On the other hand once you get it right the computer can check the output and warn everyone when it changes because of an unforeseen interaction.
Which as a developer I hate. What I really want testers to do is write automated tests. The only hand test a tester should do is one to see what the automated test should do. Yes, reality ends up being a mix, but reality should be informed by the ideal. It irritates the hell out of me that testers are doing the same thing over and over, that is what computers are for.
I am a developer and I tell my testers to consider me to be evil, lazy, and malicious. They must assume I am actively trying to fool them into thinking the application is working even if it is not with the minimum amount of work possible. That generally gets them to find the defects.
Science and medical science is NOT failing us. The compound in the article was determined not to work via the scientific method, science succeeded. The pharmaceutical industry failed to develop a drug, that is not a failure of science. The pharmaceutical industry has a problem in that they are looking for blockbuster drugs. But, what is a blockbuster drug. Lately, it seems to be something that marginally increases survivability with few side effects, so they can justify prescribing it to 100,000 people at 10x the price of a generic in order to save 2 additional lives compared to the generic.
The article mentions Lipitor as the most prescribed drug. More live would be saved with the same money by prescribing cheaper generic cholesterol lowering drugs to more people because the difference in heart attacks prevented by Liptor versus the generic is a hell of a lot smaller than the price difference.
Depends on how many sounds. Music has been around for thousands of years, there a only a relatively few distinguishable notes. So, all sequences of notes shorter than a certain length must have been copied from the public domain.
A long time ago I heard about an infringement case that said something like 4 notes was a copyrightable melody. I then heard some one calculated how many unique combinations that you can get with 4 notes including various timings of the notes and what not. It was fairly small like 100,000 combinations. The thing I always thought about that is that there is 100s if not 1000s of years of public domain music. Wouldn't that make the easiest defense to such an infringement case that you actually copied a public domain work? Even better if you can find the work.
Plaintiff: You copied these 4 notes from my defendant.
Defendant: No. Both your defendant and I copied those notes from this Beethoven symphony which is public domain.
<play 4 notes from symphony>
Judge: Case dismissed.
The real challenge would be to not identify a specific work, but convince a judge mathematically and historically that the melody in question must be public domain.
Laziness is the mother of invention
I give you the microwave oven and the TV dinner. And, I am sure many can name more.
Do not underestimate the power of the truly lazy.
"If the design looks bollocks, please tell me and we can talk it through, it's entirely likely I screwed up" and "Whilst sobbing over your PC to 4am to solve a problem might look great on your timesheet, wtf didn't you just ask me?"
This hit home. The one I run into with developers is that if it looks like I could have done something different to make your life easier, don't just code around it. Tell me. There is a good chance I either screwed up or did it right, but can make your life easier with 5 minutes of work instead of you spending 5 hours.
That is how I did it.
Alternatively you can also stop at 50*3=150 and realize the answer must be less than 150 and only one answer was available.
I am going to be a little blunt here. Past a certain ability level of the testee, multiple choice does not test whatever the test creator intended, and instead is a contest between the test creator and the testee to see if the test creator can actually make you do the problem the test intended you to do. I usually win that game.
It probably should just say remnant. Type 1a supernova are the complete destruction of a white dwarf by nuclear fusion of a substantial portion of the white dwarf's mass, which does not leave behind a core.
Probably not a good thing, but immersive Dirty Jobs. Who would not want to have the smell of an empty sewage treatment tank in their living room while watching Mike Rowe replace the lift pump.
Yes. I did the same thing and went hmmm.... free software plus $1000 in hardware to get my 20 year old $600 guitar to play with Rock Band.... Ain't gonna happen.
I aprefer.
Cost, Scope, Schedule.
Two can be fixed, one must be flexible. Cost is cost per unit time i.e. fixed number of people.
What is typical is management tries to pretend all three can be fixed. Which causes overtime and since many devs don't get paid for overtime means cost can pretend to be fixed.
Oh, and ideally the manager should have figured out how not to have it come down to late-night; but we don't live in an ideal world.
This is highly unlikely in typical development, the reason is that schedules are based on a web of falsehoods. Not lies, just things that everyone should know are false but pretend are true.
Project scope usually ends up being a falsehood, the scope changes and everyone pretends it has not and the schedule for the previous scope can still be hit. Which leads to late nights and these are typically not the fault of direct management but hte whole management structure.
Time to complete the project is usually a falsehood because estimates are made which by definition are wrong, and the schedule is set as if those estimates are fact. Is this the fault of the direct manager or the whole organization.
All of which lead to attempts to over-estimate which are bad because most of the time the project fills the time available, which means they cost more than they should.
I am sure a lot of us can think of many other things in project management that are treated as fact when in reality they are false.
One decision the manager should be making is if there is something wrong that is out of your control, perhaps the responsibility of some other development team that thinks they are done, so left on time. The manager should be there to decide whether it should be worked around, call in the manager of the other dev team to get their butt in, or call it a night and return in the morning.
Leave the devs alone and the most likely choice would probably be a work around that I expect is usually non-optimal because it is the devs ass on the line to deliver, and delivering crap that works is safer than not delivering.
That has been my experience as well, and I am by no means an expert on Agile or Scrum. I agree probably the biggest thing is the retrospective every iteration, if you don't look back at what works and what does not and are willing to change it wont work.
I also agree Scrum Master is a misnomer. I find their #1 purpose is to keep the Scrum meeting on task and short. Even removing impediments might not be their job, although making sure that some one is working on removing the impediment would be appropriate.
Agile and Scrum don't work with the above. One of the main principles is a stable development team. If you take short term hires try to assemble them into a Scrum team, then blow that team up and start over again you are screwed. (Scrum buzzords follow) You then have to rediscover velocity every time, you have to rediscover planning poker, and you never accumulate the experience and team trust that allows one to just rely on people to know what needs to be done and to brig problems to the attention of the group and leadership when needed.
It does reduce the overhead of middle management roles in particular Project Managers who are constantly scrambling around preparing schedules that end up not fitting reality, presentation about how everything is moving according to the fake schedule, and finally shortly before code delivery telling management why the due date will not be met, and giving the next fake delivery date.
I think it works if you understand what it is and what it is not. Scrum is more about project management than coding practices. It is primarily focused on addressing the fact that the Waterfall methodology is build on information the is mostly wrong. Yet, assumes that information is right. Scrum and Agile in general is about accepting that the information is bad and dealing with it. Man-hour estimates at the beginning of a project are always wrong. Schedules at the beginning of a project are always wrong. Requirements always change from what is documented.
Now the above can and should be combined with other Agile practices like Pair programming, test driven development, continuous integration and test, etc... for the coding side. And, the thing that I would not be surprised that many organizations miss which is the retrospective. My team does two week sprints and at the end of every two weeks we have to look at what worked and what did not. And, so over time we can accumulate a process that works for us.
Bringing this around to the OPs question we have actually switched who handles the Scrum Master role a couple of times trying to figure out what would work better. And, I am not sure that we have settled on the "right" solution, yet.
What about gods who think they are tech types?
"When some one asks if you are a god you say, YES!" - Winston
Actually, the LHC creates a set of circumstances that happens all the time. It just doesn't happen if front of very sensitive particle detectors at a very high rate. So, the LHC was built to replicate events that happen all the time in front of sensitive instrumentation.
So, yes, the LHC calculations could be somewhat off, but we have observations (not calculations) of events with much higher energies than the LHC can reach with cosmic rays hitting the earth's atmosphere and we are all still here. Jupiter is much bigger, so many more of those events occur on Jupiter. The sun is even bigger and many more high energy events occur for cosmic rays hitting the sun.
The calculations for LHC safety for micro black holes come from trying to put a number on the probability that if these events can destroy a planet by creating a black hole what is the probability that the Sun, Jupiter or any other planet in the Solar System would still exist given the number of high energy LHC-like events that have occurred over the last 4.5 billion years. The probability must be incredibly small, what the LHC calculations do is put a value to incredibly small.
From a doing the best thing for the athletes I think there is something to be said for the age rule giving more athletes the opportunity to compete in the Olympics
Assuming an advantage occurs at an age between 10-14 and that it is likely a girl will grow out of that advantage through puberty it creates a very narrow window within which a gymnast may compete at an Olympic medal level. It is entirely possible that with a bad birth year a gymnast might not be good enough to make the Olympics when the Olympics occur because their 2 year peak was between Olympic years.
I think an argument can be made that the 16 year rule gives the best gymnasts a chance to compete in the Olympics at least once if not twice in their career on a level playing field with others of similar maturity. I think without that rule there is zero chance of seeing a gymnast in 2 Olympics.