Professional Corner-Cutting (2016)

I agree with everything in this article. However, software developers may be craftspeople, but an infinitessimally small fraction of them are treated like craftspeople by the businesses that employ them

The reason software engineers want to push decisions to their managers is that their managers believe in nonsense like slicing up tasks into their tiniest constituent parts and meticulously estimating how much time they will take. Practices like lean and scrum and kanban are managerial conventional wisdom about how to manage a factory, not craftsperson conventional wisdom about how to make good things efficiently

As long as the people running the show are going to hold their people responsible to fiddly metrics and demand to know every detail of decisions that affect how their software people are spending their time, they will act according to those incentives, avoid making decisions where possible, quibble about every little detail

Software should be a craft. Treating it that way produces better software. In order to foment a mindset of a craftsperson, you must treat them with the trust and respect that we give to craftspeople. Most modern humans don't even have a script for interacting with craftspeople these days, and business jocks drunk on rebranded Taylorism certainly don't apply one when managing people they view as a means to better valuation

> In Coders at work, Douglas Crockford said to spend the sixth cycle - whatever the cycle is - on refactoring. It's a sound advice if you care about technical debt as an engineer.

My point is that very often it's not up to engineers. If a company doesn't incentivize this refactoring and engineers have to - as some sibling comments suggest - inflate their estimates then the code base will deteriorate over time. Even if your team sets up a policy of doing refactoring ~15% of the time this will be overridden by business interests more often than not.

This is essentially a corollary of Conway's Law. You should not expect code bases to be better than the business incentivizes it to be. I'm speaking from personal experience here; this is burnout territory. Keep in mind these are very general observations and every company is different. In some companies what you and Crockford suggest is possible. I'd wager it's the exception rather than the rule though.

> A professional developer does thorough work when it matters, and cuts irrelevant corners that aren’t worth wasting time on.

The problem, it seems to me, is that, while a furniture maker may have a reasonably stable idea of what their furniture will be used for, I think the makers of truly useful software can have no reasonable idea of the uses to which their software will eventually be put, and so must design so that the program can accommodate the demands put on it, no matter how unexpected or bizarre. How many modern security issues (I ask rhetorically) stem from design decisions rooted, explicitly or implicitly, in the assumption that the software would never be exposed to hostile actors?

This is ambiguously stepping into "overly general / building for the future" territory. Perhaps that is not what you meant.

There is a fine line where I do agree with you. Cases such as creating a relation table for categories, when you could have made a string array field instead. Or structuring a code in a way where you are not preparing for the future, but also not painting yourself into a corner.

Examples such as that do come to mind. But as I said it's a fine line.

This becomes exceptionally tricky when you are building towards a vision, but only 40% there, and having the code structured for that vision is hard to shake..

Meta's market cap is 1.2T, it has $60B cash, revenue 143B a quarter... Not a real business? I mean maybe the original team in FB should have made sure they didn't accumulate technical debt and FB having failed would be a better outcome for shareholders.

Engineers need to give the business the options. Not unilaterally decide that they're not going to accumulate technical debt. That's my point.

And trust me, business people don't assume perfect software (at least if they've been in business for any amount of time). [EDIT: What's maybe different about] business people is they a) look at things as a negotiation. b) want to get the max value for their investment c) likely have seen a lot of engineering projects from the outside. Engineering needs to work with the business not go and decide what's right for the business. This doesn't mean you don't have ethical responsibilities as a software engineer in many situations but there are also many situations where the business needs to call the right balance between engineering effort the things like quality or feature sets.