I went into this software engineering productivity research rabbit hole a decade ago and came away similarly depressed with the lack of rigor in our field. Wha

I went into this software engineering productivity research rabbit hole a decade ago and came away similarly depressed with the lack of rigor in our field. What I’ve come to believe: - Software engineering is not an engineering discipline, it is a craft. It may or may not one day become an engineering discipline, I find this impossible to tell. - The difference between a feature and a bug is largely one of semantics, not of substance. A defect is a mismatch between expected behavior and actual behavior. A bug is when the expectation was that of the programmer that wrote the code. A feature request is when the expectation was that of a user. There is no real difference for the user between a missing feature and a broken feature. Hence why we so often get side-tracked into fruitless “bug or feature” discussions and why users don’t care when we say it is by design. - Errors will happen. People are flawed and produce errors at a more or less set average rate for each person (unless they’re tired or enjoying a ballmer peak). Errors in every step of the process, from design to deployment, are inevitable. We can however catch these inevitable errors, with automated error detection tools, or by having a fresh set of eyes look at the work. The consequence is that making high quality software necessitates taking a look at the whole process and introducing error detection steps in every part of it, whether they be automated like linters and unit tests, or human like design and code review or mentoring and pair programming. - Errors in design are more costly because they cause entire features to need to be written or rewritten, which is the most costly kind of defect to resolve. We do not need research to know this to be true. We solve this by having short feedback loops with real users, which is the only real form of agile development.