[xupybd]

"Once something is in a working state there is pressure to move on to the next thing. Fighting for quality before it is in a publishable state is a devs best defence against later rework."

This insight is true and depressing. It's not the best way to focus effort. You fight for quality on a new feature that may or may not get use. By the time you know how well received the feature is it's too late to allocate resources to improving the code quality. So if you don't get it right the first time, this code might cost you months of wasted time when trying to make changes to it in the future.

It would be far better if time was allocated to going back and figuring out what parts of the code are causing problems and going back and fixing them. Spending time removing the features that don't get used.

How do you get the political buy in to do this? I have no idea.

[josephg]

Weirdly enough this came up with my life coach the other day. She said that there's a natural progression of stages for any creative work. She quoted some book or other, but she said the stages were something like, inception (having the idea), discovery (figuring out how you'll do it), doing it, then finishing it - practically and emotionally.

She thinks modern society is too obsessed with doing the work that we skip over the step of finish things properly. The result is that we don't emotionally or practically close the loop on our work. Everything is left in a "oh maybe I'll come back to that" stage.

Finishing something should involve a moment of reflection where we notice and accept that we're no longer its steward. Its both a time for celebration (Yay! We did it!) and, often it involves a bit of morning. ("Oh, that period in my life is over forever now. Huh.").

In the circles she moves in people think skipping over that step of closure is what causes burnout. For a dozen reasons we're just too keen to start the next thing, so we don't appreciate the work we've done. We don't celebrate. We don't move on. We don't clean up our code, even when we know we should. We end up feeling like we're juggling a dozen balls, because we're not really putting any of them down.

I don't know the solution to this in the workplace. But for my own work, I'm trying to find stopping points where I can take half a day off, go out for dinner and reflect on the passing of what I've accomplished. It feels really wholesome.

[nyanpasu64]

> accept that we're no longer its steward

I feel bad about past projects where nobody else has stepped up to maintain it, which slowly code-rot as people discover issues. It's as bad as unfinished projects I never had the ideas or motivation to flesh it out into something useful.

[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"?