[twobitshifter]

On the flip side, if you’ve ever been on the manager side this can drive you crazy. Something passes all the tests and you get the arguments about why it suboptimal for future usage by a reviewer. Often something we don’t know we’ll ever do and complete bike shedding. I favor getting the code in and then refactoring later based on yngni. Can that come back to bite you? Absolutely, but not as many times as you’d have been warned, so the cost benefit works out.

[bcoughlan]

Developers absolutely miss the big picture because they're mired in the tiny details. There is a tendency towards perfectionism.

That said many of us spend much of our time maintaining the half baked features of devs long gone. It's time consuming. It's reverse engineering, support cases, meetings, bug fixing, digging through vague logs, workarounds, knowledge transfers and there's never the political will to re-do it plus it's more than twice the work because you have to migrate existing customer workflows. It is work that is neither rewarding nor rewarded.

With that in mind there are categories of things that should be tackled upfront. Besides glaring bugs there is security holes, traceability, auditing, overengineering, real world performance, documentation, preventing bloat and my pet peeve - changes that slow down development by requiring duplicated work or affecting the ability to run locally.

The business pressure encourages developers to skip these because usually someone else will end up dealing with the mess.

[zoomablemind]

> ...There is a tendency towards perfectionism.

I see the perfectionism as a byproduct of a disbalanced review process.

Devs will defensively go into 'refinement' just to stave off a bounce at what is being perceived as a pedantic/senior/superior review.

If there's a practical and streamlined review process, it signals properly to devs a degree of 'good enough'.

[bcoughlan]

I have been the pedantic reviewer. It took time to learn good code review practices and grow them into the work culture, to let go of matter-of-style issues (where I can't argue an objective benefit for the change).

Asynchronous text-based code reviews suffer from an empathy problem also. A lot of the pedantic or ego attitudes drop away when you have to discuss it face to face. Nowadays I'll often opt for a call with the team member if I think there will be a lot of comments. Better yet is to do some pair programming in advance of the code review to avoid major disagreements and discarded work.

[nicoburns]

As a developer I always insist on being in the planning meetings, and I ask lots of questions about possible future plans. We then build with those in mind. That way we can add flexibility where it’s likely to be needed and avoid the cost where it isn’t.

[xupybd]

Oh yeah I'm with you on that. The ideal time to get something optimal is when it's been around long enough to prove it's self. If it's good to go get it out the door. You don't make money on features you haven't shipped.

My problem is 12 months down the track getting people to give you the resources to refactor when they get no new features out of the deal. Only the next few will take half the time to develop if you can do the clean up first. But the demand on the new feature with out way every thing else.

[CRConrad]

> But the demand on the new feature with out way every thing else.

"with out way every thing" = "will outweigh everything"?