It's awesome that Google did that. This is the first I've heard of it. But: > The thing is that the overhead for this process really only makes sense at Google

It's awesome that Google did that. This is the first I've heard of it. But: > The thing is that the overhead for this process really only makes sense at Google scale. The software industry is far larger than Google. If we want to claim that software is a discipline of engineering, we all need to have access to that kind of reference data, rather than trying to feel our way around in the dark in comment threads about blog posts about somebody's personal experiences. I won't go so far as to say there's no such thing as software engineering -- a number of people working for companies with large budgets have well earned that title, I'm sure -- but the extent to which the term is traded like currency in our industry is disrespectful to the discipline. > So you just assume that if you can get the job done in a way that satisfies the customer, it'll be wildly profitable, and the primary factor to optimize for is developer time. The fetishization of developer time is one of the problems slowing the maturation of our industry. It ignores end-user time, it ignores management time; it often focuses solely on the initial development time of a project and ignores entirely the ongoing maintenance time for a project. How many codebases are there out there that are gigantic balls of mud? How much developer time has been wasted on trying to maintain or refactor those codebases? How many really dumb security issues have negatively impacted companies or end users? How many comments has tptacek left on one little forum in one musty corner of the internet over the years trying to explain cryptographic and security-related best practices to an infinite legion of under-trained developers? How many people have lost their lives to software defects? Not even the really tricky CS stuff, I mean the kind of defects that any other engineering discipline uses as case studies in their introductory courses. Which case study would you choose for our Galloping Gertie? Certainly software has done an incalculable amount of good in the world, and its impact is far and away net positive. But while software has been busy "eating the world", it has rarely paused to also consider the cost and damage it has wrought and whether there are practices that could be standardized to reduce those negative effects. So I disagree wholeheartedly that we're not yet at the point that these things are important. Depending on who you ask, computer programming is between 60 and 180 years old. That's well long enough for us to begin asking questions like, "what data do we have to support this approach or that approach?" There is still plenty of room for experimentation and research. There is still plenty of room for hobbyists and tinkerers. This isn't an exclusive-or thing. As much as I really do appreciate blog posts like this one, and the discussion they tend to generate, and especially that there's a new one to read every single day (he said, wryly), I can't help but see every one of them as another indicator of the immaturity of our profession.