Oooh, saw Andrei's name pop up and remember his books on C++ back in the day .. ran into a systems engineer a while ago that asked why during a tech review asked why some data size wasn't 1000 instead of 1024.. like err ??
A favorite past-time back in the day was driving at night from pub to pub along the 'back roads' (B-roads specifically in the UK) as fast as 'possible'. There were typically no street lights, however lights from other vehicles showed up alerting you to any possible danger. It was fun at the time, but i wouldn't do it now .. lol ..
This is not unique to SV. This is happening world over. The wealthier are buying more assets, the middle and lower classes are left paying rent to the wealthy landowners. "Gary's Economics" has tons of material on wealth inequality and its impacts.
I went as a contractor (fixing a port from PDP 11/44 -> SUN 5/110) on-board a UK nuclear sub back in the 90s, and had a contractor berth in the 'bomb shop'. I slept underneath the Tigerfish MK24 torpedoes, smelly and greasy, but i don't remember it being cold !!
Some good stuff in there, but heard most of it in earlier publications. Reading Steve McConnell's "Software Estimation" covers a bunch of it, Cone of Uncertainty etc etc.
Here's where i've seen estimation become accurate:
1) The people doing the work are estimating the work, and KNOW the software base they are estimating for.
2) Technology being used is not shifting considerably for the piece being estimated.
3) Processes being used to go from requirements elicitation to acceptance are not shifting dramatically for the new piece of work.
You have to have probably 2 of these 3 to have any chance of reasonably accurate estimates. I've seen this work on a fairly large (1 MLOC C++) sonar system development. After a couple of 'late' releases, where those 3 premises were not true, estimation became better, and after 3 or 4 releases, teams were getting pretty accurate, such that customer trust went through the roof.
If you don't have 2 or 3 of those ticked off, you'd better add in a bunch of padding, or get some risk $$ from the C-suite signed off.
I have been involved in 2 medium sized-ish (~300) software support projects for western-nation's land forces project that brought in SAFe with a fanfare. Lots of ($$) training, everybody gulping down the coolade etc etc. It started off OK, but as with most of these ideological methodologies, our projects' circumstances started to clash with the SAFe 'way'. Our customer was very fond of his existing rituals (meetings, committees, progress meetings etc), but we also folded in all the SAFe rituals too. It seemed we were in meetings too much of the time, and we did a poor job of convincing the customer to move wholesale to the SAFe way. In addition, the organizational structure and governance models never operated in the SAFe way, with the customer's insistence on being in our shorts on every decision hampered most of the 'delegate decisions as deep as possible' philosophy. At the end of the day, it steel feels like RUP re-invented for 'agile' .. never again.
I was backpacking around Asia in '94 .. my connection to the rest of the world was my trusty Sony shortwave radio (ICF-SW1) .. anyone else remember those glorious days ? :)
Why are they still called phones though ? that's my point .. essentially you have a computer in your hands that happens to have an ability to make voice calls .. I was looking for stats on how people use their devices but can't find much actual data
Yeah, good call.. feel free to remove "Zoom" as you're reading. I agree, it's irrelevant in some aspects, however, i would posit he likened to the idea of Zoom for dismissing his staff, as he could do this without actually looking into the the 'whites of their eyes' while dismissing them.
As in so many other domains, i'm disappointed but not surprised. The corporation let this douche-bag 'cool-off' and is now bringing him back to invigorate the company .. awesome .. can't wait to see how that pans out
I've worked on reasonably large >$100M defense programs for the last 25 years. Nearly all of them overran both time and budget constraints. They have mostly been firm-fixed price, except for the last 5ish years, that being incentivized agile. I have seen estimation be accurate when the following criteria are met :
1) Experienced personnel are estimating the work (experienced technically and in the product being developed);
2) The work being estimated is of similar technology to existing product;
3) The time period being estimated is less that 6 months
If any of these are violated, e.g. new hires are given the estimation task, a years worth of work is being estimated, new technology is being estimated etc, i would not trust the estimate, and apply big 'ol bucket of risk money.