Quite simply: you don’t ship code, you ship features. You don’t ship automated dependency injection. You don’t ship elegant abstractions. You don’t ship cool compiler tricks. You ship new stuff for customers that they’ll pay for. Your high unit test coverage that makes any refactor a painful slog gets in the way of shipping features far more often than the TDD zealots are willing to admit. Most of the “best practices” in the industry is unrealistic dogma created by people in post PMF, entrenched companies that no longer need to do much to print money.
Only when your refactor only touches business logic underneath the public API. If you do a true rewrite that breaks tests, getting your coverage back up to what it was before the refactor just delays your ship date. And many engineers WILL get green bar syndrome once that coverage % goes down, losing sight of real business goals (staying alive and making payroll). I’ve seen lots of codebases where obsession over unit tests lead to tests that were orders of magnitudes more complex than the system under test. This is incredibly common in multiple process or multi device software, where there’s some sort of custom protocol over an IPC or network or RF layer. You’ll invariably see massive amounts of effort put into mocking complementary parties inside a unit test framework, when the sane thing to do is to just write a 5 line bash script for an integration level test. Or — brace yourself — just do a manual test and ship it today.
Eh, not breaking APIs other teams or customers depend on is very very important. I think broad test coverage is justified there.
Of course there are always exceptions, and testing philosophy should bend to the goals of the organization, not the other way round.
And if a five line bash script is a more suitable test than a unit test in the same language as the application, then that's what you should do. Assuming you have a good way to automate it as part of an automated build and deploy process, of course.
Engineers understand that the entire discipline is about tradeoffs. It would be extremely easy to build reliable, secure, performant, robust, etc software given infinite time and infinite budget. Engineering is about working in the real world, where you don't have infinite time or budget.
Is it correct to build a piece of software that runs 50% slower, but can be built in 6 months instead of 12? The answer is "it depends" and good engineers will seek to understand the broader context of the business, users, and customers to make that decision.
A conflict as old as time. Unfortunately, it's the MBA thinking that pays the company's bills.
An ideal world isn't one in which either the MBAs or the engineers win. It's one in which they coexist and find a reasonable balance between having more useful features than the competition and not expending too much effort to build and maintain those features.
No, it’s how anyone that’s actually worked in an SMB / non F-1000 / non household name company talks. Most “regular” companies need to focus on getting features out the door.
You are not anything until you act as something. Acting like an MBA makes you virtually indistinguishable from one. I don't care what you studied, it's what you're doing (or not) with it.
Your entire stance is no true Scotsman with ad hominem. You realize almost every YC company operates in the way I described until they become entrenched in their domain, right? Do you think pre PMF companies are bickering about unit test coverage? If they are, they’ll fail
It's really a basic point that I can call myself whatever I want, but if I walk and quack like a duck, I'm a duck.
YC is a VC firm which is a very specific context that demands things like revenue and growth to be so prioritized as to be implicit and core features of the working ideology. That's not really a good model for software engineering when it comes to social benefit -- it prioritizes something else. It can demonstrate incidental social benefit but that's not actually an incentive that's built into the system that YC operates in and reflects internally.
There are Scotsmen out there, they're just not part of this discussion. That doesn't make anything I said a "no true Scotsman" argument.
Shall I prepare the postage for the letter in which you'll call John Carmack an MBA? Should we send another to Chris Sawyer? I heard he didn't even write a formal design doc for Roller Coaster Tycoon!
You've either intentionally cast my argument as something it's not or you need to read a little deeper before replying.
Nowhere did I say sloppy code is the problem, what I said was justifying it in terms of profitability is the problem. There's a difference between cranking something out because you're excited to show it and rushing through an implementation because of this or that externally defined money-based KPI.
