Comment by dt3ft
3 years ago
We can’t even push to a git repo unless it has a linked work item/story/task/bug.
So, in order to say, upgrade packages or refactor difficult to read code, the work item needs to be approved by a non-tech PO.
Guess how much gets done outside of planned/micromanaged? Answer: next to nothing.
That definitely sounds broken. I have a hard rule with my PO: 30% of the sprint is mine (read: the team's). He only gets to schedule 70% of the stories according to his priorities. I use that 30% for tech debt, primarily, but sometimes for spike projects and other things that interest us.
It sounds like SOC2 compliance requirements unfortunately. Plus process overhead on who can raise tickets.
I've found compliance makes it harder to write good code. If you get a PR approval with optional suggestions you're heavily disincentivised from actually addressing those comments since if you push those changes you now need to wait for review again.
Like everything process and compliance it's designed by low-confidence managers with an inate distrust of their teams.
I fundamentally disagree with this.
In our product, a change has the potential to cost businesses lots of money and also bring our customers into legal trouble, potentially making us liable too.
That's why we have heavy-handed change control, code vetting and so on. Yes it makes things slower, but due to the risks involved.
I've also worked on embedded projects where field updates are HARD and costly. We had heavy-handed change control then.
When I put those controls/processes in place, it wasn't due to low confidence, it was due to confidence in two things: (a) even the best SWE makes mistakes and (b) work to control change risk pays off
Sure, it isn't appropriate in many chases, but to write-off process as being designed by "low-confidence managers" because you don't see the point, is a bit myopic.
Any SWE who thinks that a codebase doesn't benefit from review before merging is driving on ego.
3 replies →
My company is soc2 compliant and we don’t need work items to push code. Certain changes need to be approved, but they can be approved by a software engineer on one of the approving teams for the repository.
As a product manager I appreciate this take. Lots of bureaucracy is caused by a few base requirements for compliance/governance required by laws or customer need. It’s a huge time suck for PM and engineering, but I don’t know if this is avoidable. Maybe more automated verification systems?
1 reply →
I like this in a certain light. It's not so much a problem that PRs should be associated with tickets, it just sounds like the gatekeeping involved in getting tickets into an iteration is horribly overbearing. There _should_ be work happening that is driven by technical wants and needs, and the PO should be amenable to that.
Yeah - team members are also stakeholders and improving dev experience by allowing refactoring is something that needs to be taken into account.
Unless company does not want to have any devs working on that project in the future. But it would be just like not wanting customers to use that project.
Guess how much would get done if you learned to explain why that work is important to a non-technical colleague? Lots. People don't always understand code, but they do understand problems, and why those problems are important to keep on top of.
If your PO is sensible then a couple of paragraphs explaining why refactoring is important with a closing line that says spending a week catching up on refactoring now will save 4 sprints of work in a year's time will get you the time. People aren't stupid. Once they understand why something is necessary they've very receptive.
Also, add refactoring time in to your estimates in the future and you won't end up in this situation, plus the code that's committed will be better.
Do your non tech colleagues need to have approval before saving a spreadsheet or writing a doc? Do they need to plan it out in tickets weeks ahead of time and get sign off before starting their work? Then report status daily on their progress?
One of my friends is a technical writer and she is amazed we put up with this on the engineering side. No one would ask it of other professionals.
>Guess how much would get done if you learned to explain why that work is important to a non-technical colleague? Lots.
From my experience, this is more a cop-out than anything else. At some point I'd expect you understand children with a track record of doing as they are told and informing you of important details do not need to be strictly parented around every corner. To expect that very thing from adults with way bigger incentives to behave feels off.
This is like needing to ask to go to the toilet. It's degrading. Utterly disrespectful. You expect people to stick around?
Updating a dependency, refactoring some code, or just making a 'simple' change sets off a chain of events that affect other people. The other devs need to review the code, the QA team need to test it, and then regression test the rest of the app, the devops team need to deploy it, the legal team need to update the legal documentation that lists the licenses for the dependencies the code has, the technical writers need to change the docs if the update has a visible impact for users, and so on, all across your org.
What looks like a small change to a developer is never actually a small change.
I really hope there aren't that many people impacted when you go for a piss.
4 replies →
Explaining why maintenance is necessary time and time again (tech evolves fast) is soul-crushing and quite frankly rather demeaning. I need x amount of hours for maintenance work every sprint, or the codebase will slowly become outdated and undesirable to work with. Again, tech evolves and changes rapidly, open source packages die quite often. Maintainers abandon their packages (my PO likely has no idea that we rely on free open source software to ship features), there are security issues with using abandoned packages… To sum up: when I see issues, I want to fix them. If I have to go through a corp process and ask for time to fix the issues… I sort of tend to lose the apetite/mood. This right here is the core issue.
> spending a week catching up on refactoring now will save 4 sprints of work in a year's time will get you the time.
In my experience that’s very rarely if ever the case. Managers will always favor features over fixes in the kind of company that ends up with a crippling tech debt problem. They got there by not listening to engineers and having salesmen managers. These companies never change and no manager wants to be the one who’s fixing things for the next manager after they get promoted. People are idiots (maybe) but they respond to incentives. And very often the incentive is that problems that may arise in a year or two are someone else’s problems so not worth fixing now.
> We can’t even push to a git repo unless it has a linked work item/story/task/bug
Exactly the same where I work. The pace of getting things done is absolutely glacial compared to what you know you could achieve if you had any agency. I think the only reason this organization I'm temporarily a part of can even compete is that all its competitors must be equally inefficient.
But when something major breaks, and the answer to the question of "why?" is ... "well, I just thought i'd make that change, but nobody asked for it" what happens then?
I wouldn't want to be accountable in that situation.
Every change carries risk.
And what if the same major thing breaks but you were asked to do it? Your necks on the line and you did something wrong that you were asked to do correctly. The problem is that part of current micromanagement environments isn't just about micromanagement but also passing down risk and responsibility to developers.
You can do the change work in a feature branch and propose the idea after the fact. If there's interest "I've already done it." Stakeholders get a bit of instant gratification like their request just materialized into thin air. If they're not interested, don't mention it and let the work go unused, rack it up as professional development time and work.
I do this fairly often. If a decision has a bunch of real risk associated with it I make sure to get sign off and create an appropriate evidence trail to pass risk back up when it's passed down. Much of work is just passing risk and liability around to PYA.
6 replies →
Why is it any better if someone further removed from the change is accountable instead? Major breaks shouldn't be avoided by avoiding change, They should be avoided by having strong QA process & support - it shouldn't be a single-person accountability.
I don't believe this is how it is actually implemented in _most_ companies. Where I work every PR must have a linked story / bug / etc but anyone has the rights to create a story so it acts more as a way to track what changes actually goes into a release for x-teams to review and see if they need to document it, etc.
In regard to refactors, people tend to just squash them into another change they are making. This makes the git log a bit harder to follow at times, but people did this back when we just used to push to trunk too so I don't think the story is the deciding factor.
You wrote: <<I don't believe this is how it is actually implemented in _most_ companies.>>
I would say for non-tech companies with a strict set of IT guidelines, this is mostly true. Please ignore non-tech companies with weak or zero IT culture. It will be the 'Wild West' at those places! Nothing will be maintainable beyond a certain size because there will be so much key person dependency.
For pure tech or tech heavy (banking, insurance, oil & gas, etc.), there is frequently more flexiblity, including "dummy Jiras" just to track a non-QA'able code change like upgrade C++ / DotNet / Java / Python library, or refactor some code. In my experience, 'Jira-per-commit' rule isn't awful, as long as tech debt does not require non-tech approval, and the ticket is just a tracking device. (A few different vendors offer very nice total integration between issue ticket, bug ticket, pull request, code review, etc.) Just a one liner in the Jira should be enough. In my experience, the best teams try hard to "do what works for us", instead of be a slave to the Jira process. Yes, I realise this is highly dependent upon team and corporate culture!
Finally, I would be curious to hear from people who work in embedded programming -- like automotive, aeronautical, other transport, and consumer electronics. I have no experience in those areas, but there is a huge number of embedded programmers in the world! Do you also have a very strict 'Jira-per-commit' rule?
I get why bureaucracy is a total pain, getting work approved by stakeholders constantly ...
But the actual ticketing/PR system? Change requires control.
The actual issue is not _using_ that control tool to get the right things done. If basic technical debt issues are not an easy sell in your org, that's the real problem and one that should be handled by senior/dev manager.
A big red flag for me is any org that doesn't recognise and service technical debt and empower engineers to make a win.
I also wouldn't say tech debt pay-off should be without its justification in some cases. If an engineer can't measure the positive impact of doing something, it can make it a hard sell. Why should an engineer spend 2 weeks doing something if we can't describe the payoff?
> But the actual ticketing/PR system? Change requires control.
The ticket system isn't for engineers. If it were for the engineers, they wouldn't be continually forced to use it. The ticket system is for the legibility of management or sometimes compliance (other flavors of management). This visibility is at the expense of the productivity of the engineers themselves.
> Change requires control
No, fundamentally, change is gated by control. The more control, the less the change, with sufficient levels of "control" leading to no change.
Requiring a "non-tech PO" to upgrade a package is just broken, though. PMs are good at some things, but giving them power over every minute of an engineer's day is a recipe for badness.
Agreed. I'm not sure I'd let anyone who wasn't from a hands-on SWE background decide the priority of technical work.
Of course, in some cases, it is right to say "Here's the problem, and what could go wrong if we don't fix it. You need to accept the risk".
It's a sad fact of life that technical problems need to be sold to non-technical people as they're often the ones shouldering the risk.
Part of my day-to-day is selling tech debt pay-off work to clients who have to pay for it. They rightly ask "why should we pay for this?".
I think in 99% of cases (like your package upgrade example) the systemic failure is elsewhere and the approval is often meaningless and inefficient.
> Change requires control.
But code, unit tests, git commit messages and merge requests are already providing 4x documentation of code changes. Adding Jira tickets and production deployment documentation gets you to 6x documentation.
In my experience, if your company's problems weren't solved with 4x documentation, they won't be solved by going to 6x documentation.
I'm not sure that's a like-for-like comparison and if those things overlap like that, it sounds wrong:
- Ticket: Description of the requirement
- Code: How it was done
- Review: Peer-learning, change evolution
- Unit test: Testing of implementation as understood by SWE
- QA: Did the change match the requirement, did the SWE understand it? Is the outcome the right one?
Each "item" should serve a distinct purpose, have distinct value and be justified. If they seem like duplicates, then that probably points at issues elsewhere.
4 replies →
Requiring it to be documented and approved is just responsible from a change-management perspective. At my company we have similar requirements and it is basically required to do that in order to meet security audit expecations. The problem is when they managers don't let you have a say in what gets done.
If a developer on our team things something should be done and can do it quickly, they are encouraged to create a ticket and do it. It gets code-reviewed and accepted. If it is not a quick change, they need to bring up the ticket at a planning meeting to make sure it is balanced against other priorities.
What happens if you do it anyway and don't put it on the board?
In my company it depends on the repo but worst case is you get arrested for making unapproved changes to regulated sports betting systems.
This made me laugh out loud because it was so unexpected but also makes perfect sense.
In the unlikely event that such a repo gets deployed to prod without any oversight?
Ouch. Out of curiosity, are those local or federal regulations?
1 reply →
You wasted time on something that doesn't get you out of PIP, into promotion, or a higher salary. At companies that micromanage, I would imagine your direct manager is the sole owner of your performance rating.
I'm not trying to get a higher salary or promotion. I make enough money. I can't say for certain since it has never happened but I would probably quit on the spot if PIP'd.
Why would you do that?
Worst case, you get criticized for doing unauthorized work.
Best case, you spend your time on a task that gets unnoticed, and now you have to do overtime to do stuff that you are assigned to and actually supposed to do.
I don't mind criticism. I've been chewed out before. I refuse to work overtime and if push comes to shove I'll find a new job.
Why would I do it? Bit of a rebel I guess.