Tangentially related but in Australia we run a household utility company that operates of that same assumption: https://www.amberelectric.com.au/
Our hypothesis is that market signals combined with the right tools (friendly app and home automation) can help households shift demand into less carbon intensive periods.
"The legendary former champion Garry Kasparov suggested the draw offer was a sign that Carlsen was losing his nerve, and on Twitter he proclaimed Caruana the favorite in the tiebreakers. “They’re entitled to their stupid opinions,” Carlsen said with a smile of his critics after his victory."
I have a recollection of seeing a study once that found the best balance point of review time vs dev time but haven't found it again. I recall it being somewhere around 20-30% but now that I can't find it I'm questioning my recall.
I definitely overstated here sorry. Found the excerpt I was remembering in my copy of code complete "On a project that uses inspections for design and code, the inspections will take up about 10-15 percent of project budget and will typically reduce overall project cost".
So assuming the same payoff benefit (big if, but let's go with it) between PR style reviewing and more formal inspections, every engineer should be spending around four or five hours a week performing reviews to hit the sweet spot.
> For sure, it's important to keep an eye on the code review culture, though. It's easy for code review to degenerate into nitpicking small things like whitespace, naming, coding conventions - these should be handled by tools instead.
I agree with this, but think there needs to be some balance. My experience has been that people generally add rules over time while rarely removing them - usually to quell disagreements without regards to the benefit of standardising the answer versus the cost of more rules.
That's not really true. A better formulation is that there's no way to manage programming productivity cheaply and/or non-intrusively.
I agree that the bulk of X vs Y comparisons are emotive and subject to what Alan Kay calls the "pop culture" but that in no way demonstrates that measurement is out of reach. It's just in most contexts we don't care to do the work to measure it out of personal preference or economic reality.
Good point, productivity measurement is probably possible, but so vastly expensive enough that it's not happened yet.
I really like this post and the one about managers programming btw. Your common sense explanation to why most new managers end up coming back and reporting that they shouldn't code is exactly what I've seen as well.
In it he has a pretty interesting insight about late projects. "If a project offered a value of 10 times its estimated cost, no one would care if the actual cost to get it done were double the estimate. On the other hand, if expected value were only 10 percent greater than expected cost, lateness would be a disaster."
I imagine as our field matures measuring productivity and hitting estimates will get more important once software has finished eating the world. The unlimited (or close to) upside dev projects will be largely behind us and we'll need to hit tighter economic targets. I'm just glad I'm working in the era where I don't need to measure it :D
You are the first person I've talked to who also thinks the "eating the world" will come to a natural end! I think the natural conclusion is that in X years there will be only a fraction of the number of working programmers as today. The margins will get tighter, and the gains smaller.
It is sad in a way, but also exciting as you say to be in the golden age.
Mind you, the maintenance burden and the dependency of the users on the legacy will be ever larger. Also - as things are digitized the opportunity for more and more digitization grows.
I think that DeMarco is wrong about that already in the corporate world. The budgets and schedules that I work with are organised around knowing what is going to arrive when, crudely 10x -> 5x means that 5x is not available for the next round of projects, which means that 5 projects get canned. Any project running 2x will result in a big change of "staff responsibility" basically because no one trusts anyone involved any more.
> Integration with your test framework and programming language
any indication which languages/frameworks? I've got a fair sized typescript monorepo with a build/test cycle I want more insight into