I don't actually disagree with you, Jolas, but I find your treatment here naive and off-putting. Bear with me and I'll explain.
First, As edA-qa mort-ora-y mentions, this is not a stark dichotomy, nor is it some sort of pitched battle. You want to ship good code to satisfy a customer. Your manager wants to satisfy the customer. You're both (ultimately) after the same goal.
In fairness, you state this, but after you've pitched the programmer/manager dichotomy.
Furthermore, I take issue with:
"Similarly, going by that analogy, it is unprofessional for programmers to bend to the will of managers who won’t be able to understand the risks of making messes."
I can't say this clearly enough: It's not your decision. Unless we're dealing with F/OSS you don't own the intellectual property you're creating. Stridently pitching a fit to management citing some sort of "professional standard" isn't professional, helpful, or even compassionate. #PragProg, chapter one: Offer options, not lame excuses.
Next:
"And most importantly, you will not make the deadline by making the mess. Indeed, the mess will slow you down instantly and will force you to miss the deadline. The only way to meet the deadline — the only way to go fast — is to keep the code as clean as possible at all times."
This is provably false. Sometimes you do make the deadline by incurring technical debt. Making statements like "the only way" discredits your argument, because one can cite examples when you copy/pasted some code (or something similar) to get stuff out the door, Delivering Results.
Last in your summary:
"Instead of writing bad code and meeting deadlines prefer writing good code even if you miss deadlines."
First, I agree.
However, a professional developer will engage with Product Management about tradeoffs long before it comes to the "line in the sand" moment. To me, driving consensus and a great experience for the customer needs to be the goal, without devolving into "us"/"them" dichotomies with management.
Best wishes, sir. Thanks for putting yourself out there and sharing your views.
Stridently pitching a fit to management citing some sort of "professional standard" isn't professional, helpful, or even compassionate. - I disagree. As edA-qa mort-ora-y said, the clean code does not necessarily need to be pristine but it should be okay level clean in such a way that it is easy for maintenance. Making the product work with bad code will meet the goal of satisfying the customer, temporarily. But, when it comes to maintenance phase or feature addition you will spend even more time due to your technical debt, which both manager and developer don't wish to spend at a crucial stage when the customer wants the product to get its bugs fixed.
I don't actually disagree with you, Jolas, but I find your treatment here naive and off-putting. Bear with me and I'll explain.
First, As
edA-qa mort-ora-ymentions, this is not a stark dichotomy, nor is it some sort of pitched battle. You want to ship good code to satisfy a customer. Your manager wants to satisfy the customer. You're both (ultimately) after the same goal.In fairness, you state this, but after you've pitched the programmer/manager dichotomy.
Furthermore, I take issue with:
I can't say this clearly enough: It's not your decision. Unless we're dealing with F/OSS you don't own the intellectual property you're creating. Stridently pitching a fit to management citing some sort of "professional standard" isn't professional, helpful, or even compassionate. #PragProg, chapter one: Offer options, not lame excuses.
Next:
This is provably false. Sometimes you do make the deadline by incurring technical debt. Making statements like "the only way" discredits your argument, because one can cite examples when you copy/pasted some code (or something similar) to get stuff out the door, Delivering Results.
Last in your summary:
First, I agree.
However, a professional developer will engage with Product Management about tradeoffs long before it comes to the "line in the sand" moment. To me, driving consensus and a great experience for the customer needs to be the goal, without devolving into "us"/"them" dichotomies with management.
Best wishes, sir. Thanks for putting yourself out there and sharing your views.
Thanks for sharing your thoughts Harold Combs.
Stridently pitching a fit to management citing some sort of "professional standard" isn't professional, helpful, or even compassionate. - I disagree. As edA-qa mort-ora-y said, the clean code does not necessarily need to be pristine but it should be okay level clean in such a way that it is easy for maintenance. Making the product work with bad code will meet the goal of satisfying the customer, temporarily. But, when it comes to maintenance phase or feature addition you will spend even more time due to your technical debt, which both manager and developer don't wish to spend at a crucial stage when the customer wants the product to get its bugs fixed.
100% in agreement with Harold. Try working in a large company where the IP isn't yours.