Comment by Tyrannosaurs | Hacker News Reader

Comment by Tyrannosaurs | Hacker News Reader

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.

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.

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.

"... 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.

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.

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.

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.

> 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.

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".

What promise? The point was that the managers won't promise anything.

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.

"Sometimes"? That's like saying that SOMETIMES rain is wet.

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.

Generally when you explain to people what you want to do but also agree to do what they've asked for they're relatively happy with the trade-off. My experience is that people aren't against things being done properly, it's only an issue when that gets in the way of what the feel really needs to happen.

If you come up against people who really just won't listen I tend to make a note of the fix, log it as a bug and include it in the next round of bug fixing, the next bit of quiet time or whatever. Alternatively include the refactoring into the estimate the next time I'd have to do significant work on that module.

Two other points while I'm rambling:

Always make sure that the refactoring is genuinely necessary and not just polishing. Some developers like "perfect" solutions but often this results in over engineering and significantly increased timescales. The key question I find useful is "am I coding for a specifically stated requirement or probable edge case or am I extrapolating to what I think might be useful / needed in the future?". I'm with Kent Beck on code only for what you specifically need today.

Secondly, only real issue with this approach I've outlined is if someone micromanages your time so heavily that you can't do any of that AND they won't listen to reason. In that instance you might want to consider your options but I've only ever once been in that position.

Reply on news.ycombinator.com