The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
Unfortunately it appears the only new technology they can find is HTML 5, which has no where the potential of their XAML.
History will tell.
Clifford Nelson wrote:
Actually it is very old technology that has been patched to attempt to up with things like Silverlight, and it does not do a good job.
I think flash was a bigger target than Silverlight, but in any case a unified video provider is a step in the right direction. Having said that Apple will continue to go it's own way with a proprietory video standard, but what else can you expect from Apple.
I am not so sure HTML5 is not the right way to go because it unifies all platforms, not just Microsoft.
The report of my death was an exaggeration - Mark Twain
This is about the Delete key... And I still haven't figured out a workaround.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- "Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997
Estimating: A good, detailed estimate with task breakdowns is very reassuring if you are using it to make a budget decision or a go/no-go decision. If you already know what you want to do (eg the top stuff on your prioritized backlog), then estimating is a waste of time. It reduces productivity by wasting time. That’s true in a startup and it is also apparently true for the bigger projects in our “Scalable Agile Design Group” survey. Our analyst talked to 12 of these project leaders and came back with this summary:
Some Agile textbooks recommend estimate development times for tasks, then measuring actual results against estimates. But members of this group were cautious about making estimates, and downright opposed to evaluating people and groups based on actual versus estimate comparisons. Most managers expressed one or more of these views:
Estimates of software tasks are inherently unreliable.
The benefits of estimates are outweighed by the time required to make them.
Most developers won’t take the time to enter actual hours.
Measuring people against estimates sends the wrong signals and will distract people from being flexible and innovating.
Measuring people based on estimates causes them to game the system.
I think this is pretty spot on, what are everyone else's thoughts?
You cannot argue with agile people so just take the extreme approach and shoot him.
And it's pretty hard to estimate the amount of time that one is going to be hanging out in the CP Lounge from one day to the next.
Why is common sense not common?
Never argue with an idiot. They will drag you down to their level where they are an expert.
Sometimes it takes a lot of work to be lazy
Please stand in front of my pistol, smile and wait for the flash - JSOP 2012
Yeah. Whenever anybody asks me for a time estimate I cringe, and I have been doing this for quite a while. Little stuff you can estimate pretty well, but then trying to estimate they number of little things that need to be done can be difficult. From what I have heard, when programmers estimate, they tend to double it, and quite often that is right. What happens is management they halves it.
A rational management will understand a fundamental rule that military analysts get drummed into their heads on Day One at the War College:
The map is not the terrain.
A plan, with attached estimates of time and cost to completion, is a map; the actual enterprise of:
Solidifying the requirements;
Gathering all the relevant specifications for the inputs and the outputs;
Designing the solution;
Coding the solution and performing alpha-testing;
Composing a beta-test procedure and contriving to get it executed by competent beta-testers;
Coping with the screams of outraged customers to the effect that "That's not what we want;"
...is the terrain -- and a harsh, irregular, rock-strewn land it is. However, rational managements are about as rare as sensible liberals.
Possibly the best approach to the production of an engineer's estimate goes as follows:
Take a SWAG at it.
Double the numerical figure in your SWAG.
Whatever the time unit in your SWAG (i.e., hours, days, weeks. months, years), replace it with the next higher one.
Thus, if your SWAG is "two weeks," publish an estimate of four months.
Why? Simply: That won't be the final schedule, and the final schedule is what really matters. The procedure above attempts to account for all the following:
Changes in requirements.
Management's inevitable attempt to bargain you down.
Distractions, diversions, and deflections.
Delays in the acquisition of necessary items (e.g., file formats and test data).
Unavoidable "learning experiences" ("What do you mean, you don't know RPG-II? Everyone knows RPG-II!")
I've been using the above procedure for about thirty years, and it's served me well...because it's based on realities we'd like to wish away, but can't:
Requirements will change.
Management will meddle.
We all think we're faster, smarter, and more accurate than we really are.
There are always other things that will demand our attention.
Nothing is ever ready when those who've promised it to you said it will be.
So you think you know how to code a B*-tree from scratch, eh, hero? Think again!
Murphy never sleeps.
In my experience both as an engineer and a supervisor, a competent engineer's SWAG is within 25% of exactly accurate nearly 90% of the time...if all those other perversities could be excluded. But that's not the world we inhabit, and it never will be.
A final thought: Sometimes one of the perversities can be turned into a weapon you can wield in your own defense. This is the case with management's arbitrary truncation of your estimate: that makes the estimate their responsibility and their property. Document this with emails and journal entries, such that if you exceed management's Procrustean schedule, you can remind those lofty souls about what you originally said, and how they reacted.
Everything is easy for the man who doesn't have to do it himself. -- Author Unknown.
(This message is programming you in ways you cannot detect. Be afraid.)
Interestingly, the "upgrade the unit and multiply by two" approach was also adopted by IBM at an early stage. I've found that in general (unless you get really lucky, which can happen) it's a fairly representative method of working it out.
This takes me back to Stars Trek II: The Wrath of Kahn:
Spock: Admiral, if we go "by the book". like Lieutenant Saavik, hours could seem like days. Kirk: I read you captain. Let's have it. Spock: The situation is grave, Admiral. We won't have main power for six "days". Auxiliary power has temporarily failed. Restoration may be possible, in two "days". By the book, Admiral. Kirk: Meaning you can't even beam us back? Spock: Not at present. Kirk: Captain Spock, if you don't hear from us within one hour, your orders are to restore what power you can, take the Enterprise to the nearest star base, and alert Starfleet Command as soon as you're out of jamming range.
Does that mean that Starfleet uses IBM's guide?
ragnaroknrol: Yes, but comparing a rabid wolverine gnawing on your face while stabbing you with a fountain pen to Vista is likely to make the wolverine look good, so it isn't exactly that big of a compliment.
I do a lot of production support and often get asked, "How long is it going to take to fix this problem?". To which I reply, "What do you want me to do? Waste time figuring out long it will take to fix or would you rather me just figure out why it is broke and then fix it?".
I am Canadian. [heard in a local bar]
In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
posting about Crystal Reports here is like discussing gay marriage on a catholic church’s website.[Nishant Sivakumar]
Most managers expressed one or more of these views:
I would really like to meet (and work for) those managers. Come on. I have NEVER worked for a manager that realized that estimating software tasks are inherently unreliable, or the rest of those points.
There are two categories of tasks: have to do, and would be nice to do.
If you want to control time, then manage competently (aye, there's the rub) the "have to do" tasks by HOW they are done. Prioritize the "nice to do" tasks so you get the most bang for the buck, which yes, does involve a WAG at the estimate.
I've recently seen one developer go off on some obscure tangent of technology (that only he knew about) to write what sounded like little more than a parser. What's insane is that his manager didn't discuss what the problem was and his recommended approach for solving it. Nor did the developer talk to the rest of the team. It was several weeks before we discovered this "waste of time", and by then it was too late.
Management is not about estimation and pretty PowerPoint slides that they use to BS their management with. The worst scenario (and I've worked in many) is that a company doesn't fully grasp the investment needed (time and $) required, yet they have this idea that because they have some smart people it should be cheap. Ultimately, it's a lack of communication between management and developers, and quite frankly, I think we developers fail in that communication quite a bit!
Intelligent discourse in the Lounge? How dare you!
Panic, Chaos, Destruction. My work here is done.
Drink. Get drunk. Fall over - P O'H
OK, I will win to day or my name isn't Ethel Crudacre! - DDEthel Crudacre
I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer
Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
Management is not about estimation and pretty PowerPoint slides that they use to
BS their management with.
Most management cannot differentiate between managing tasks and managing projects.
And I only say most because I hope that one such exists.
Managing tasks is the process of defining, estimating and tracking actual parts of some delivrable. Managing a project is the process of tracking delivery expections and fitting the task planning into that. Trying to managing them as one is very likely to represent the difference is not understood. One uses task management and the prunning of it to better fit project expectations.
I would broadly agree with this. Rough estimates of when I'd like to get something off my pile are okay but anything else is just nonsense. Non-technical project managers use estimates like cudgels to beat developers with - very, very unproductive. Sure, I can tell you roughly how long a job might take under perfect conditions but when was the last time you worked under perfect conditions? Never, would be my guess.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum
Any work sufficiently interesting will be very hard to estimate time for. It's a sad day when you only work on things with no novelty or variability. Sure, I can produce an estimate, but the actual work may vary from that estimate by 300%.
I worked in a group where program managers were held to within 5% of their project estimates. Corporate spent lots of money on consultants and tools. We spent several years being micromanaged daily by having to spend an hour or so a day updating our status into the tools. The result was the program managers could watch the forecasts (we called them wiggle charts) get larger day by day. So they knew exactly when they had exceeded their 5% margin of error.
After the first set of program managers moved on because of missing their targets, the next set of program managers came up with a clever solution. They institutionalized sandbagging. The result was that nobody got fired, but we couldn't actually do anything because the estimated cost of any project was astronomical. The result was that no project appeared to make financial sense - clearly that was wrong too.
Now we use scrum. Though it has issues too (like not begin able to accurately estimate end dates), but from an engineering point of view it's much better than most other processes that we've tried and discarded.
I agree that micro-estimations are a liability, but I don;t get much work at all without an upfront estimation, and I often lose there, so I'm moving toward a staggered delivery with an estimation for each phase, which is a step back toward micro-estimations.
Last Visit: 31-Dec-99 18:00 Last Update: 21-Jun-18 6:29