I'm a small business programmer. I love solving tough problems with Python and PHP. If you like what you're seeing, you should probably follow me here on dev.to and then checkout my blog.
Thank you for your comments, David. Let me see if I can clarify my thoughts.
What I'm trying to communicate in the first quote is that business people may not understand the consequences of pushing the devs to take a shortcut. They have their own priorities and objectives and if they can get the devs to deliver a new feature in x weeks, then that helps the business people meet their short term goals and they are happy. But if the devs sat the business people down and explained all the consequences of adding this shortcut to the other 2,000 shortcuts already in the system and how each added shortcut makes it that much harder to do anything in the future, and that their two best devs just quit over the low quality of the code base, they might be able to convince the business people to do something less distructive to the health of the software. Most devs don't push back against the business people or at least take the time to explain the damage certain proposed changes are likely to do to the software. When devs fail to advocate for their code, that's not very professional behavior in my books (and according to the Software Engineering Code of Ethics and Professional Practice).
In my second quote, I'm arguing that the devs can't afford to take a hard line either. There may, in fact, be very good reasons to damage the health of the software to achieve an important short term business goal. For example, it might be worth hacking in some new business rule if it meant keeping your biggest client and avoiding bankruptcy.
Both these quotes support the overall thesis of my post, which is that we need to have better cross-functional communication to make our maximum contribution to the success of the businesses for which we work.
I'm a small business programmer. I love solving tough problems with Python and PHP. If you like what you're seeing, you should probably follow me here on dev.to and then checkout my blog.
I forgot to address one point. A dev adding a 300th method to a class at my work isn't creating technical debt, he's writing crappy software that's not going to pass code review.
So we are probably in slightly different work situations. You're battling crappy code so, yeah, you probably aren't aware of the effect of the business people when you've got stuff like that going on.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thank you for your comments, David. Let me see if I can clarify my thoughts.
What I'm trying to communicate in the first quote is that business people may not understand the consequences of pushing the devs to take a shortcut. They have their own priorities and objectives and if they can get the devs to deliver a new feature in x weeks, then that helps the business people meet their short term goals and they are happy. But if the devs sat the business people down and explained all the consequences of adding this shortcut to the other 2,000 shortcuts already in the system and how each added shortcut makes it that much harder to do anything in the future, and that their two best devs just quit over the low quality of the code base, they might be able to convince the business people to do something less distructive to the health of the software. Most devs don't push back against the business people or at least take the time to explain the damage certain proposed changes are likely to do to the software. When devs fail to advocate for their code, that's not very professional behavior in my books (and according to the Software Engineering Code of Ethics and Professional Practice).
In my second quote, I'm arguing that the devs can't afford to take a hard line either. There may, in fact, be very good reasons to damage the health of the software to achieve an important short term business goal. For example, it might be worth hacking in some new business rule if it meant keeping your biggest client and avoiding bankruptcy.
Both these quotes support the overall thesis of my post, which is that we need to have better cross-functional communication to make our maximum contribution to the success of the businesses for which we work.
I forgot to address one point. A dev adding a 300th method to a class at my work isn't creating technical debt, he's writing crappy software that's not going to pass code review.
So we are probably in slightly different work situations. You're battling crappy code so, yeah, you probably aren't aware of the effect of the business people when you've got stuff like that going on.