5 ms·

Developers should absolutely push back and make sure that the person requesting the change has all the information needed to make a good decision, however they

Developers should absolutely push back and make sure that the person requesting the change has all the information needed to make a good decision, however they also need to understand that they, the developer, may only have part of the story and that they need to respect that the decision is coming from someone who may understand things that the developer does not. Yes too often developers are ridden over roughshod, but I think it's important to put the other side of things. In the same way that person may not understand the consequences of the dirty hack, the developer frequently will not understand the consequences of delaying the change. Unless the developer can honestly say that they understand the relevant part of the business better than person making the request, some humility and willingness to compromise and discuss is likely to be appropriate. For me the issue is not with doing the hack, it's getting the agreement that we'll do the quick hack, but only if we're then allowed, in the very short term, to make the fix properly. That way everyone gets what they want - the fix is made in the timescales the business deem necessary and the developer isn't leaving a mess for future developers to have to clear up. Being a professional programmer in a commercial environment isn't about sticking rigidly to some definition of what's "right" (which will often vary from one developer to another anyway), it's about using code to fix real problems and provide real benefits in ways which are appropriate to the situation and balance all the variables. It's a variant of the old "good coders code, great coders ship". Being a great coder is about finding ways to meet everyone's needs.

deleted 16y ago
[deleted]
zeemonkee 16y ago
Shouldn't the business people in the organization also learn to understand the consequences to the company of poorly managed development processes and technical debt ? It works both ways.
- endtime 16y ago
  Yes, and that's what Tyrannosaurs is saying. The article is what's one-sided - it doesn't seem to understand that (unless you work for e.g. 37 Signals) software is in service of the business, and at the end of the day everyone's there to make money for the business.
  - BCGC 16y ago
    "... at the end of the day everyone's there to make money for the business" Really. It seems to me like everyone's there to make money for their departments / business units / lines of business.
    - endtime 16y ago
      Well, my company has only has 4 people full time, so maybe my perspective isn't representative. :) But I've had people who were writing code on a temporary basis get frustrated when things didn't stick to the spec 101% or when there wasn't time for them to follow all the software engineering practices they read about in a book and felt like trying...I understand all that stuff (I've been on both sides of the equation), but what bothers me is when people are inflexible on principle, to the detriment of the business.
- Tyrannosaurs 16y ago
  Absolutely it works both ways. The reason I posted from the position I did is that too often in these discussions there is the assumption that the programmer understand the business well enough to make the call which in my experience is false. The reality is that in these situations you have two people each of whom understand part of the problem. Simple black and white declarations of right or wrong by either party are unlikely to result in an optimal solution to the whole problem.
ciupicri 16y ago
> we'll do the quick hack, but only if we're then allowed, in the very short term, to make the fix properly. What happens when you're not allowed to fix/improve/refactor the hack? Sometimes developers are assigned new tasks immediately.
- btilly 16y ago
  Then the promise has been broken, you nag them about it, and the next time you use it as why you won't do it. Never say, "You're lying" though. Instead say, "once burned, twice shy".
  - ciupicri 16y ago
    What promise? The point was that the managers won't promise anything.
    - btilly 16y ago
      What promise? The point was that the managers won't promise anything. The promise that you'd get time to do the fix. Which didn't happen. That was how I read: > > we'll do the quick hack, but only if we're then allowed, in the very short term, to make the fix properly. >What happens when you're not allowed to fix/improve/refactor the hack? Sometimes developers are assigned new tasks immediately.
      - Dylanlacey 16y ago
        "Sometimes"? That's like saying that SOMETIMES rain is wet.
  - dedward 16y ago
    If you're a good politician, that may help you push the right buttons - but unless you can show concrete business damage because of the choices made, you are still likely on the nasty end of the stick. Nobody cares whether the developers are happy with the code - they care whether the code solves their problem or not.
msmith 16y ago
I was just about to make the very same comment, but you've said it much better than I would have. In my experience, these requests that initially seem unreasonable will often have a very reasonable explanation. If you take the time to understand the motive, then will often be able to find some alternate solution that satisfies both the business and the developer needs.

deleted 16y ago

[deleted]

zeemonkee 16y ago

Shouldn't the business people in the organization also learn to understand the consequences to the company of poorly managed development processes and technical debt ? It works both ways.

endtime 16y ago
Yes, and that's what Tyrannosaurs is saying. The article is what's one-sided - it doesn't seem to understand that (unless you work for e.g. 37 Signals) software is in service of the business, and at the end of the day everyone's there to make money for the business.
- BCGC 16y ago
  "... at the end of the day everyone's there to make money for the business" Really. It seems to me like everyone's there to make money for their departments / business units / lines of business.
  - endtime 16y ago
    Well, my company has only has 4 people full time, so maybe my perspective isn't representative. :) But I've had people who were writing code on a temporary basis get frustrated when things didn't stick to the spec 101% or when there wasn't time for them to follow all the software engineering practices they read about in a book and felt like trying...I understand all that stuff (I've been on both sides of the equation), but what bothers me is when people are inflexible on principle, to the detriment of the business.
Tyrannosaurs 16y ago
Absolutely it works both ways. The reason I posted from the position I did is that too often in these discussions there is the assumption that the programmer understand the business well enough to make the call which in my experience is false. The reality is that in these situations you have two people each of whom understand part of the problem. Simple black and white declarations of right or wrong by either party are unlikely to result in an optimal solution to the whole problem.

ciupicri 16y ago

> we'll do the quick hack, but only if we're then allowed, in the very short term, to make the fix properly. What happens when you're not allowed to fix/improve/refactor the hack? Sometimes developers are assigned new tasks immediately.

btilly 16y ago
Then the promise has been broken, you nag them about it, and the next time you use it as why you won't do it. Never say, "You're lying" though. Instead say, "once burned, twice shy".
- ciupicri 16y ago
  What promise? The point was that the managers won't promise anything.
  - btilly 16y ago
    What promise? The point was that the managers won't promise anything. The promise that you'd get time to do the fix. Which didn't happen. That was how I read: > > we'll do the quick hack, but only if we're then allowed, in the very short term, to make the fix properly. >What happens when you're not allowed to fix/improve/refactor the hack? Sometimes developers are assigned new tasks immediately.
    - Dylanlacey 16y ago
      "Sometimes"? That's like saying that SOMETIMES rain is wet.
- dedward 16y ago
  If you're a good politician, that may help you push the right buttons - but unless you can show concrete business damage because of the choices made, you are still likely on the nasty end of the stick. Nobody cares whether the developers are happy with the code - they care whether the code solves their problem or not.

msmith 16y ago

I was just about to make the very same comment, but you've said it much better than I would have. In my experience, these requests that initially seem unreasonable will often have a very reasonable explanation. If you take the time to understand the motive, then will often be able to find some alternate solution that satisfies both the business and the developer needs.