6 ms·

I honestly don't encounter non-trivial merge conflicts in practice on a team of 5 developers. Our repos are scoped roughly to be team-sized so the velocity is l

I honestly don't encounter non-trivial merge conflicts in practice on a team of 5 developers. Our repos are scoped roughly to be team-sized so the velocity is low enough to know what everyone is working on. I guess some of this advice applies better to repos where a large number of people are working on it. I couldn't imagine giving up the quality gate factor of PRs. Carving out the time to dissect changes catches so many bugs (although it can be received harshly sometimes compared to face to face). Also pushing to master vs. long lived feature braches is a false dichotomy. You can have small PRs on short-lived branches that may not be a complete feature but can be merged without making the main branch unreleasable. There is also the political factor to consider in companies where product and sales people control the selected work items. 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. The CD community is overly obsessed with velocity. Of course removing obstacles can lead to a smoother faster workflow. Take it to the extreme and it becomes a dopamine hit activity, the goal is to merge changes fast and we become unable to take the time to think deeply and reflect since it is clear that we are valued by our rate of commits over smart decisions.

xupybd 5y ago
"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.
- twobitshifter 5y ago
  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.
  - nicoburns 5y ago
    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.
  - bcoughlan 5y ago
    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 5y ago
      > ...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'.
gizdan 5y ago
> The CD community is overly obsessed with velocity. I think CD is about minimising the amount of code released in one go, which allows you to catch issues much faster and revert issues much quicker. Compare that to something most banks do, release once a quarter, and you'll get stuff like that UK bank that went down for days (can't remember which one it was). I've yet to meet anyone saying you have to finish your features faster.
- dpark 5y ago
  Velocity is also highly valuable because if you can get your code in front of users worldwide rapidly, you can more quickly “page out” that code and move on to the next work unburdened. Once you know your code is released fully and working, the cognitive overhead is greatly reduced because multitasking is reduced. The tradeoff is that if you are pushing your code worldwide in an hour and you shipped a critical bug, your high velocity also creates outsized negative impact.

xupybd 5y ago

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

twobitshifter 5y ago
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.
- nicoburns 5y ago
  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.
- bcoughlan 5y ago
  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 5y ago
    > ...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'.

gizdan 5y ago

> The CD community is overly obsessed with velocity. I think CD is about minimising the amount of code released in one go, which allows you to catch issues much faster and revert issues much quicker. Compare that to something most banks do, release once a quarter, and you'll get stuff like that UK bank that went down for days (can't remember which one it was). I've yet to meet anyone saying you have to finish your features faster.

dpark 5y ago
Velocity is also highly valuable because if you can get your code in front of users worldwide rapidly, you can more quickly “page out” that code and move on to the next work unburdened. Once you know your code is released fully and working, the cognitive overhead is greatly reduced because multitasking is reduced. The tradeoff is that if you are pushing your code worldwide in an hour and you shipped a critical bug, your high velocity also creates outsized negative impact.