I really enjoyed this read. This is often why I think things like TDD is a waste of time. Customer’s never see the tests. It is impossible to say a test has direct value to a customer. However, it is always possible to compute the dollar amount that test costs the customer.
Overkill on unit testing is one area modern engineers need to learn to cut costs. There are smarter ways to make sure your code works the way you expect.
you aren’t building a cabinet, you’re building a cabinet-making machine. the quality of the cabinet you deliver to the customer will absolutely depend on the quality of the machine you build to build it, but corners you cut on the machine could make your life a lot harder even if they don’t show up in the final cabinet.
Cutting corners should feel like you have a clear focus and you’re skipping tasks that don’t matter for that focus. Cutting corners should not feel like you’re doing poor-quality work.
This matches my experience almost perfectly RE which shortcuts will come back to bite you.
Interesting analogy. Let’s change it to espresso machines because I think that’s a little more clear. The consumer of espresso doesn’t care about minor details in the machine, as long as the drink is good. The barista probably cares a good deal more about ease of operation, ergonomic controls, etc.
yes, that works a lot better. i’ve noticed that “developer usability” is often not enough of a concern, especially when features need to be shipped yesterday. the code may be solid and tested, and deliver a good end-user experience, but still be needlessly hard to work with due to corners being cut in that area.
I really enjoyed this read. This is often why I think things like TDD is a waste of time. Customer’s never see the tests. It is impossible to say a test has direct value to a customer. However, it is always possible to compute the dollar amount that test costs the customer.
Overkill on unit testing is one area modern engineers need to learn to cut costs. There are smarter ways to make sure your code works the way you expect.
you aren’t building a cabinet, you’re building a cabinet-making machine. the quality of the cabinet you deliver to the customer will absolutely depend on the quality of the machine you build to build it, but corners you cut on the machine could make your life a lot harder even if they don’t show up in the final cabinet.
Cutting corners should feel like you have a clear focus and you’re skipping tasks that don’t matter for that focus. Cutting corners should not feel like you’re doing poor-quality work.This matches my experience almost perfectly RE which shortcuts will come back to bite you.
Interesting analogy. Let’s change it to espresso machines because I think that’s a little more clear. The consumer of espresso doesn’t care about minor details in the machine, as long as the drink is good. The barista probably cares a good deal more about ease of operation, ergonomic controls, etc.
yes, that works a lot better. i’ve noticed that “developer usability” is often not enough of a concern, especially when features need to be shipped yesterday. the code may be solid and tested, and deliver a good end-user experience, but still be needlessly hard to work with due to corners being cut in that area.