[mclin]

I like this quote:

Perhaps my biggest advantage is that, while I do spend some time coding, when I think about our software I am not constrained by the fear that I will have to implement my own ideas. It may seem crass, but as someone who has worked long years in the trenches I know that there is a subconscious tendency to discount ideas that may have huge long-term benefits if it means a lot of work in the short term.

Hate to admit it, but it's true. It's something you fight against.

[gaius]

Someone who isn't hands on can't make decisions on behalf of those that are. What have they got to go on but hype and vendor white papers? Only if you are immersed every day can you see the forest for the trees.

[mclin]

Sure, but as the guy talks about in the article, he is hands on. He just spends a certain fraction of his time trying to maintain a global picture of the project and applying insights that come from that.

I haven't worked on a project with more than 4 people for ages, but I don't think I would mind this.

[div]

If 2 viable solutions have this kind of long term vs short term trade off, technical decision makers need to talk to business decision makers.

Often it's reasonable to incur some technical debt with the short term solution, and then switch to the long term solution later on.

Delaying work gets you to market faster, costs less, and means you understand the problem better for less effort.

Obviously, if it's not a feasible roadmap to go with option a first and migrate to option be later, it's the techie's job to make this abundantly clear to the pm / business.