3 ms·

You've fallen into a common trap. A trap that many developers and managers do - that software is the goal. It's not. Software is a means to an end. A tool we

by npinguy 13y ago

You've fallen into a common trap. A trap that many developers and managers do - that software is the goal. It's not. Software is a means to an end. A tool we built for users and customers to solve their problems. Software that doesn't solve the customer's problems might as well be gravel on a beach. Software that is shipped, but isn't maintained, will diverge from customer's needs as they change. And will become just as useless. So are you trying to precisely understand a customer's key requirements? Then you best represent them in unit tests. Are you building and releasing iteratively and getting customer feedback to make sure that customers are getting what they actually need? (A lot of times what people say they need changes once they actually get what they ask for) Then you need to be able to refactor frequently and fearlessly, and you best have tests. Are you considering future releases after shipping major versions? Same, you will need to refactor, and you will break existing functionality, and you need tests. I understand you want to be pragmatic. But don't think that the people that preach TDD are just sitting there in love with their best practices for their own sake. We have just been burned too many times and believe the best process and framework for delivering customer value via software is to build on a solid foundation.

ap22213 13y ago
EDIT: On second thought, I think it's an interesting topic of conversation. When I'm working, my primary goal is to make money. And, when I'm working for a client or boss or customer, that means being responsive and showing them value for _their_ money. Oftentimes, this means trying to protect them from themselves, but, again, I want to get paid. So, eventually, despite all my arguments, it turns back to me shipping software. They want to 'see' something for my expensive invoice, subscription fee, or salary. The payer doesn't care about all that 'stuff' that I do that they can't 'see'. So, yes, you're right. I do sacrifice quality at times to ensure that I get paid. It's not intentional. No way. But, I am a biased participant in this debacle: I have a perverse incentive to ship non-perfect software. I don't intentionally try to do so, obviously. But, there is an equilibrium point where I stop arguing and see that I can fix it in v2. Now, on my personal projects, I actually take my time. I do things the right way, because I have time on my side. I'm my own boss. And, in those cases, I actually do write full sets of unit tests. Interesting for me to observe this in myself. Thanks. But, yes, when I'm working for someone, I have considerable pressure to break the rules. You're right - it is a trap.
- npinguy 13y ago
  Fair play. I certainly know that pressure too.

by npinguy 13y ago

ap22213 13y ago

EDIT: On second thought, I think it's an interesting topic of conversation. When I'm working, my primary goal is to make money. And, when I'm working for a client or boss or customer, that means being responsive and showing them value for _their_ money. Oftentimes, this means trying to protect them from themselves, but, again, I want to get paid. So, eventually, despite all my arguments, it turns back to me shipping software. They want to 'see' something for my expensive invoice, subscription fee, or salary. The payer doesn't care about all that 'stuff' that I do that they can't 'see'. So, yes, you're right. I do sacrifice quality at times to ensure that I get paid. It's not intentional. No way. But, I am a biased participant in this debacle: I have a perverse incentive to ship non-perfect software. I don't intentionally try to do so, obviously. But, there is an equilibrium point where I stop arguing and see that I can fix it in v2. Now, on my personal projects, I actually take my time. I do things the right way, because I have time on my side. I'm my own boss. And, in those cases, I actually do write full sets of unit tests. Interesting for me to observe this in myself. Thanks. But, yes, when I'm working for someone, I have considerable pressure to break the rules. You're right - it is a trap.

npinguy 13y ago
Fair play. I certainly know that pressure too.