[kybernetikos]

So this is all true, however it is surprising how often in development you find people spending more time and effort getting the 'pragmatic' hack to work acceptably than it would have taken to do it right.

People often underestimate the difficulties of getting a hack to work and overestimate how long doing something correctly will take. Even with short time horizons.

[eCa]

> People often underestimate the difficulties of getting a hack to work and overestimate how long doing something correctly will take.

Yes. And sometimes one of those people is your boss.

[pm90]

Most of the times, I would say. Perhaps the biggest tragedy of Software Development today is how few managers actually do/have done enough software development to qualify managing those who do.

[WalterBright]

Part of the job as a software engineer is to inform your manager as to the tradeoffs and the correct solution. Especially if well paid.

Surely, there are bosses who won't listen. But of the ones I've worked for, nearly all would listen to a reasonable explanation of how best to achieve the goals, and would approve recommendations from below.

If you've got a track record of being right, that helps a lot :-)

[pm90]

I agree. And the managers I've worked with: I'm glad they were there so that I personally didn't have to navigate the company hierarchy. But I strongly feel that the managers who were in the past good software developers have a much better idea of how to be managers...those who weren't, I've noticed a misplaced desire to prove themselves, which has hurt me personally.

[meatysnapper]

Management has two goals: 1) Make themselves look like they contribute value: Micro-manage projects, track time spent, etc. Even if there's nothing achieved, they can claim to be doing something and organizing meetings. 2) Swap out programmers like cogs in a machine. 3) There is no incentive to have good quality code because chances are everybody will be off the project in a year or so, so you take credit for the success and place the failure on the poor SOBs who have to maintain the system.

[cyan_atrus]

i think you might be misunderstanding the point of managers..

[socceroos]

True, but he does paint an interesting, if not accurate picture of a significant proportion of the managers out there.

[mreiland]

I personally hate working with people who put things in terms of 'right' and 'wrong', or 'correct' and 'incorrect'.

I honestly believe the key to software development is good decision making. If you're thinking in terms of right and wrong, correct and incorrect, then you're not making decisions, you're simply doing the right thing over and over again. Only it may not be the OPTIMAL thing, or the smart thing, in any specific instance.

For example, who here really believes proponents of unit tests have never painted themselves into a corner? How did that happen? By making poor decisions.

Stop thinking in terms of right and wrong. Seriously. Sometimes unit tests are a good decision, sometimes they're not. Sometimes that hack is a good decision, and sometimes it isn't.

You make a decision on a case by case basis, not because it's right.

[kybernetikos]

> I honestly believe the key to software development is good decision making.

I agree, and the purpose of my comment was to point out that I have often observed people making decisions on a case by case basis, and repeatedly making bad decisions by underestimating how much effort the solution thought to be 'quicker' or 'easier' or 'minimal change' option is compared to the solution thought to be more 'radical' or 'unnecessary effort'.

You seem to have some specific bone to pick around testing. I'm not really interested in that. When I say 'right' or 'correct' in this context, it's generally about not being blinkered by the current state of your codebase. People get so used to the fact that their current codebase does things in a particular way, they often look at problems as situations where they have no choice but to force the problem into the frame of their code. Solutions where you solve the problem with something closer to what you would want to write if you didn't have to worry quite so much about the peculiarities of your current codebase generally scare people, but are often the better decision not just from some academic point of view, but literally from an execution, getting-things-done quickly point of view. 'correct' as I use it in this context is mainly a shorthand for that concept.

The whole point here is not to say that there's some secret that avoids you from having to make decisions, it's to say that many people in the real world are making a particular class of error in decision making. Signs that a particular decision might fall in that category include:

1. the main trade off being considered between the options is developer time

2. none of the developers actually think the believed-to-be-quicker-to-implement option is a good option apart from its supposed quickness to implement.

3. other options exist where a significant fraction of developers agree that apart from their supposed slowness to implement, they are good options.

[nine_k]

I like the idea of finding a good decision in the context of a current situation. I don't like the idea that terms like 'correct' and 'incorrect' should not be used. For some problems, there exist exactly correct solutions (like adding integers). The lack of a well-founded or at least well-known correct solution is what forces you to look for an optimal solution made of trade-offs.

[mreiland]

If you read back over the the thread it will quickly become apparent that your example is not relevant within the context of this conversation.