This is why management needs to be technical. Otherwise you just end up with feature, feature, feature … death.

Technical and smart. Otherwise you end up with fix tech debt, fix tech debt, fix tech debt ...death.

I have also seen refactor, refactor, refactor, oh actually it's now no better than before. Whoops!

It's like imaginary tech debt.

Or even worse than before - and the sad part is that no-one intended that to happen. All bespoke software is effectively an experiment that may fail. I've become a lot more wary of the "failure is good" mantra that SV is famous for - it's not good in a zero-sum game where labor is spent on stuff that gives no value, and refactoring for DX is definitely expensive but only possibly valuable.

This is why management needs to be competent. Average CEO is 58 years old. Their first jobs were in the late 1980s.

The economics and tactics around technology has been revolutionized a dozen times over in the last 4 decades. Now, maybe a few rare individuals have kept up, but most likely, they all rely on outdated strategies from out of touch MBA programs & buzz words.

Its the same reason the market kills public technology companies' innovation and they rely on acquisition.

Its like gunpowder has just been invented and leadership still wants large formations marching against each other. "what if we invested in medical training and add washing our hands so we can keep more people alive?" "nah, more guns and marching"

Funnily enough, the best managers I've had are all in the late 40s - mid 50s that all did 20 years in the "trenches" and decided that management was the new path forward for them as they started to prefer people work to technical work.

I think its work experience that matters most with management. You need folks who are people oriented but understand the job that the folks they manage are doing, and the challenges that come with it, both obvious and non obvious, and can communicate the importance of such work to the broader organization

There was an article posted here a month or so ago about how this guy was seeing a new class of worker emerge who both understood the necessity of absorbing knowledge from other domains and enjoyed the process. It reminded me of a dev I worked with who'd go on smoke breaks with the art department and then change data structures we'd been using forever.

I was under the assumption this type of worker is what dominated before the industrial revolution constrained people to a small domain in a process. Some may call it artisan, dilettante, etc. Maybe the narrow-domain specialist was the anomaly and not the rule when we expand our lens across history.

I assume these "smoke breaks with the art department" involved more than just tobacco.... :D

> The economics and tactics around technology has been revolutionized a dozen times over in the last 4 decades. Now, maybe a few rare individuals have kept up, but most likely, they all rely on outdated strategies from out of touch MBA programs & buzz words.

Ah, the cult of youth. It is cute, when it isn't killing startups with rookie moves.

It almost sounds like you think management is something like practicing law - like there's a set of rules that are revised on a schedule and they need CLE credits to keep them current.

You had me with competence, but you lost me with blatant ageism

Your gunpowder and large formations metaphor doesn't hold. People aren't idiots, on the whole. Do a little more military history research.

Particular people can be utter cretins, they've crashed the world economy in 2008 and nearly caused global nicl3ar war by sheer stupidity:

> the Russian nuclear sub B-59, which had been running submerged for days, was cornered by 11 US destroyers and the aircraft carrier USS Randolph. The US ships began dropping depth charges around the sub.

Officers aboard had every reason to believe that their American counterparts were trying to sink them.

Cut off from outside contact, buffeted by depth charges, the most obvious conclusion for the officers of B-59 was that global war had already begun.

The submarine was armed with 10-kiloton nuclear torpedos and its officers had permission from their superiors to launch it without confirmation from Moscow.

Two out of three serior officers onboard agreed to launch, but unanimous vote was required.

I did say, "on the whole."

I was specifically thinking of the idea that large formations being idiocy after the invention of gunpowder. Brett Devereaux's 4-part series "The Universal Warrior" had an excellent discussion of why a unit of soldiers might fight in large formation. https://acoup.blog/2021/02/12/collections-the-universal-warr... He's verbose, but thoroughly enjoyable.

This says more about the kind of places you've worked than anything else.

>Its the same reason the market kills public technology companies' innovation and they rely on acquisition.

The counter-theory is that as companies mature, they have to devote a disproportionate amount of time to maintenance. From that perspective, it's a risk-based approach to maintain the products and services that already have a market and instead effectively out-source the high risk operations of innovation. New companies don't have comparatively much to maintain, so they can focus on innovation. It's not quite such an either-or, but a balancing act. It's just easier to balance when you can outsource risk.

>Average CEO is 58 years old. Their first jobs were in the late 1980s.

I believe there's some neuroscience theory that may illuminate this. When we're young, our intelligence is more plastic and can more readily innovate. But as we get older it becomes more crystalline. What we may lose some of that novelty generation, we can gain in understanding the greater levels of experience. Experience is necessary for putting ideas in their appropriate context. I would argue that understanding context is more important at high, strategic-level positions.

Maybe it's just me, but basically all the best senior managers I've had have been in their 50s and with plenty of experience under their belt. I've had one or two in their late 60s who where starting to lose touch with the field, but most managers in their 50s I've found have kept up pretty well.

> Its like gunpowder has just been invented and leadership still wants large formations marching against each other.

Incidentally, marching large formations against each other has been the dominant strategy for most of Gunpowder's history. Only in the last 150 years did guns become lethal enough to make this a bad idea.

Reminds me of the ill-fated cavalry charges in WW2. Many older officers insisted that "the fundamentals of war are the same" despite new technology.

I can imagine a modern tech leader living in those times and giving the orders to charge the German panzer formation, sabers overhead.

I find management only really ends up being a problem if they get too deeply involved in the contents of technical quality work. If they're limited to budget allocation it's actually better to have them involved.

I almost always tell management that by default I'm spending, say, 30% of my time on technical quality and ask if they'd like to dial it up or down temporarily because of a holiday or a deadline they can. I will track this and show it to whomever asks (e.g. their boss and boss's boss might be interested if they've explicitly asked for 8 straight weeks of 0% work on quality).

What falls under technical quality label?

Refactoring, CI maintenance, test automation maintenance, that sort of thing - everything except user visible features or bugs, essentially.

Even technical management can succumb to this. Agreed with most of the replies to your comment.

>You can theoretically avoid it with enough trust

I think it ultimately comes down to human values. What's important to the founders and the team? Do they have a clear articulation of those values? KPIs are useful if they're grounded in values that the organization absolutely won't compromise on; KPIs should be a means to an end, not the end themselves.

Whether those values are "we want to make the most money" or "we want to make customers happy" or "we want a sustainable lifestyle for our team," KPIs will only help you pursue them, not define or prioritize them.

Nothing in OPs comment says it should only be completed stuff that goes into the status.

Also, if your team is optimising for the status report, your manager has already failed you.

Aurornis didn't say that. He specifically said "because they won’t sound good for the week".

With time and experience, you'll learn that those who can quickly churn out features and bug fixes are deemed extremely valuable to the company.

Let's say we have a wicked bug that has very little chance of happening. But if it does, it'll bankrupt the company, no questions asked. Spending 3 weeks fixing it is nowhere as impressive to the company as Joe who's churned out 10 features per week while your status updates are "Hunting for the wicked bug", even if you describe it it more details.

Even if the detail was something like, "if this wasn't fixed, we were at the risk of losing half our customers" ?

> Even if the detail was something like, "if this wasn't fixed, we were at the risk of losing half our customers" ?

Yes, because this one task appears as a single line item for the manager's manager. They don't care for the complexity or consequences until the fire actually happens. And if the fire happens, they just blame engineers.

If the industry incentives were changed such that manager heads would roll for mass outages, managers would start appreciating big fixes.

If you spend more than a few hours looking for a bug, you should start writing code to go around the bug completely. Even if it results in technical debt, if the company can go under if the bug isn’t fixed, you’d be stupid NOT to charge that TD card.

That’s why devs who understand that survive layoffs and the ones who spend three weeks “hunting for an extinction level bug” don’t.

You are describing a situation where management has failed. No amount of better practices can help in a situation where your management chain cannot evaluate your work correctly.

Yes. The manager has failed you. Doesn't mean you should put your ass on the line to fix things for the business.

That's why these kind of incentive structures are dangerous and why things like OKRs put such heavy emphasis on regular, company wide, failure. (I.e. they punish 100success rates)

> if your team is optimising for the status report

If you're providing a status report, you're optimizing for the status report. Period.

Eh, my personal experience has been that just as often we have a mandatory status report that nobody cares about (including my direct and skip level managers). It's just something that needs to be done for contract compliance.

I admire the confidence with which you hold this opinion.

Engineers are not providing status reports. The manager is collating them. How is it any different to a sprint summary?

Here is the thing, in a high-trust environment, KPIs work fine too. In fact, almost everything work on that condition.

But modern organizations are quick to destroy trust on any whim.

The place I'm consulting for at the moment shut down offices for years due to the pandemic. Some people moved out of state and continued to work because there was no signal of ever returning to the office. Then last week they said everyone had to return to the office 3 days per week or be fired with no exceptions. We're losing an MVP on our team due to this. He now lives over 500 miles from the closest office.

The way around this is to open an office just for them. It sounds dumb, but it meets the business requirement, and could also drive further recruitment around their location.

It seems like it'd be way more sensible and efficient to just make an exception for that particular employee (and maybe some other important ones). Though, in my opinion, the best option is to just let anyone work remotely as much as they want. Especially if you go years without ever indicating you intend to return people to the office.

I think I'm luckily grandfathered in due to working fully remotely for years before the pandemic, but if that happened to me I would absolutely start looking for a new job.

That can be more expensive than it appears at first, especially if it's in a different state due to taxes.

I've asked before if I can work remotely for a few weeks at a time and have been told yes, as long as I don't leave the state. In some places, just moving to a different county or city can trigger different tax requirements.

If you have competent accountants/payroll, this is no more complicated than anything else. There might be a learning curve to get things set up properly, but the rest is reasonably normal.

It can be quite complicated.

> State corporate or other business activity taxes can apply, if even a single employee is working in a state. In effect, if an employer did not previously have a recognized office in a state, but one employee starts working from there, this can trigger entirely new registration requirements and tax liabilities. It may be necessary to register with the secretary of state and relevant tax authorities, provide a registered agent address, and pay corporate and business activity taxes, sales taxes and employment taxes, including employee withholding. There are often state and local licenses and business permits as well.

https://www.adp.com/spark/articles/2022/06/implications-of-w...

Sounds like business as usual for most accountants that do SMBs. Worse case scenario you do this 50 times. The same thing happens in the EU when an employee works in another country, only worse. Sounds like you’ve got it pretty easy compared to there.

I think you underestimate just how small most businesses are. In the US, something like 90% of businesses have fewer than 25 employees. Dealing with setting up in another state is a significant burden.

I don’t think you understand how this works. At some point, you will surpass the sales tax threshold for most states. Then you’ll be reporting and filing taxes in that state anyway. Adding an employee in a state is not complicated by that point.

So sure, if you’re a company doing only local sales. Or a company doing less than 3-400k of revenue a year, this is probably complicated. Once you hit ~1m in revenue, there is probably AT LEAST one other state you are paying taxes to. Adding states should already be a defined process (or being defined) and an employee moving there is only a one or two lines different.

In the premise Consultant32452 provided, the employees had already moved and been working from different states, so presumably all of that would already have had to be done.

A lot of states made changes during the pandemic to allow remote workers. Those have all been ending over the past year and I assumed that’s what they were talking about.

What? I do not see how any state could not allow remote workers.

And all states have long required employers to register with the state government for tax purposes if they employ someone working in the state, as well as comply with the state’s labor laws.

I didn’t say that right. What I meant to say was that a lot of states allowed remote workers to live there without having to pay local taxes.

I don't think expense is the driving force here. It would be even less expensive to simply let the worker work remotely. The reason a company wouldn't do this is that it would send an unacceptable message about worker power. If some workers could get exceptions to a new unpopular rule, then why can't everyone? And if everyone could, why have the rule at all? This does not serve the interests of the company's power structure.

That seems rather shortsighted to just assume offices won't reopen instead of actually negotiating a transition to fully remote.

They tried this one of my client's office too, but the middle-management all stood firm that if they and their teams (I'm on one of the teams) would not be returning. And to fire even one person on any of the teams would mean certain death for the company since it only has a handful of developers and everyone has 7-14 years of in built knowledge. I am the most recent consultant hired, and I was hired in 2017.

They back peddled pretty quickly and switched it to anyone within 10 miles of the office has to come back. There is only 1 person that close. He's the "office mom" and he's been in basically every day since the pandemic started.

Even if half the teams hadn't moved further away, there is no way most of us would have gone back to commuting 2-4 hours per day.

I've found the same.

We used goals and velocity metrics on the highest performing team I worked on. This was also a high trust team that happily raised concerns and adjusted priorities/velocity/etc.

The goals and velocity were still extremely useful for getting everybody on the same page for what we were looking to accomplish and how long it would take. We needed to land in the general area, but never got caught up in meaningless drivel over metrics.

The problem is management wants consistency and expects an explanation when things change. I've found it a team is perceived as failing if they're actually realistic with goals and capabilities.

A hallmark of strong high trust environments I've found is that management beyond the team (or squad, or pod, or whatever you call it) is only concerned with Milestones, not sprints or other velocity metrics, and the check-ins with them revolve around the progress on the given Milestone(s) the team is working on.

It is up to the team to decide on the best way to approach this, and what works best for that team, and the team is free to do the work as they see it, with the only requirement that if something does negatively affect the Milestone(s), it gets raised quickly and early, in case of re-adjustment.

This however, means:

- Product management has to be competent enough to present a relatively elastic vision that is not so concrete its essentially a waterfall, but not so vague that its unclear whats being built. Wireframes are usually a good signal here.

- Engineering Management has to be competent enough to communicate (or allow others to communicate) technical challenges that may be involved, and more importantly, what may be unknown, to Product management

- Everyone has to agree that demoing work is more important than talking about work, whenever possible

- Trust in everyone doing the right thing needs to be high, constant interference and meetings will kill this from working right.

Yeah, it's like the way in a competent team, just about any software development methodology will work well. The hard bit (honestly, the impossible bit) is making things work adequately with a mediocre team and mediocre leadership.

There are two types of devs at my job, those that care about shipping lots of new things fast, using new frameworks and pushing metrics. Then we have me and a few others fighting fires that the fast shippers leave behind. I’m fine with it, I enjoy analyzing database queries and figuring out what to index. As long as manager understands where the fires are coming from and why we need to spend time putting them out there’s no problem.

Unfortunately, at far too many companies, those "ship new things fast" developers are the ones who get promoted, get rewarded with the best projects, and grow their careers and influence, while the firefighters just keep fighting fires.

I'm curious if anyone has stories about making this work in the long run.

It seems like such a natural division of labor that it appears everywhere. But I also feel like I've never seen a company explicitly optimize processes around it.

So I'm curious to hear any battle stories.

The problem that I'd imagine is a variation of "Why does Sales get paid so much?". Basically, the more obvious the connection between your contribution and the company making more money, the easier it is to reward you with a slice of the pie.

In a codified "trailblazers and firefighters" model, the trailblazers are much more obviously tied to the company's bottom line. Feature X is required to close deal with company Y, this software team built this feature. Meanwhile, the people frantically cleaning up the mess the first team left is only nebulously connected to the company raking in more cash, relegating them to a second-tier position despite having harder work.

Yes, our team asks for demos every sprint which I find to be dumb and a remnant of every sprint needing a MVP when in practice that is just hilariously naive. Especially considering a screen that took 10 minutes to make is considered much more interesting than code that is more detailed really doesn’t lend itself to a “demo.”

Without an outstanding company culture, most KPI are almost useless.

While working at a big corporation we had a velocity initiative supposedly aimed to lead the company toward continuous integration.

"How long a PR stays open" was one of the KPI in a dashboard.

I said: "Be careful with that!"

People started to close PRs and reopen new PRs with the same code.

Middle managers and sometimes the person in the division that was the point of contact for the velocity initiative were asking to do that.

The script measuring this KPI was improved to look at the branch and the diff of the code. Result? people changing branch and EOL encoding in the new PR

Learnings? B and C players with questionable ethics screw companies quite rapidly.

In this climate KPIs and aligning them with company values is futile.

When I worked at a FAANG ~15 years ago, a new VP came in and heard, correctly, that our group didn't have enough automated tests. He created a requirement that every developer commit two new tests to the code base every workday. He had automation put in to monitor our compliance.

Within a couple of weeks, scripts were circulating to auto-generate and auto-commit tests. If the JVM we were using had a bug in adding random numbers together, we'd have known about it very quickly.

That's about the time I decided I should move on. I'm glad I did. The company I joined treated developers like adults and developers acted like adults. And we had great automated test coverage.

Obligatory mention: https://en.wikipedia.org/wiki/Goodhart%27s_law

I'd argue that the point Goodhart's law isn't that metrics are bad, but that all metrics aren't created equal. In the case above, it seems like the real goal was improved code quality. Number of unit tests isn't the best proxy for that goal, so it wasn't the best choice of metric. You don't want developers creating tests for the sake of creating tests. (There's some irony here in that it's not the type of behavior I'd ascribe to professionals). The "solution" is a metric that's a better measure of what you actually want.

Even professionals have limits. I've worked in companies with the kind of management which kept adding this bad proxy metrics and pushing initiatives which had a totally expectable bad effects on the product quality. Most devs used to fight the management on this, but grew progressively tired of this continuous fight. At some point the experienced devs either left or just gave up and started giving the management what they asked. Us juniors followed suit. The management was happy, the actual workload diminished because we let go of "low priority" tasks and we even go a juicy bonus at the end of the year because of how good we were doing.

The company tanked six months after that, now it doesn't exist anymore.

There's only so much you can do when the management is hellbent on doing stupid things.

You might be misconstruing the point. I certainly wasn’t insinuating more and more metrics. If anything, it’s the opposite: a core understanding of what’s really important helps you focus on the few metrics that matter.

In that context, I’m not really sure what point you’re making, unless it’s just to share a personal anecdote. Are you implying that management shouldn’t have any quantitative measures and should only be qualitative?

You need good quantitative measures, not just random numbers.

If you sell, say, water bottles, you probably want to know how many of them you can sell at any given moment, in order to not overbook and have to reimburse people. In this case, keeping track of how many water bottles you do have in stock probably helps, keeping track of how many labels with funny jokes you can stick on a shipping box in an hour doesn't. But if you start tracking the latter and handing down bonuses and layoffs based on it, people will max that metrics out - at the expense of your actual stock capacity.

Quantitative measures are dangerous, especially in the hands of people who believe they are better than qualitative ones because they're "objective" or whatever. Because not only they aren't, but they are also better than qualitative ones at hiding their biases and soothing your own.

> Are you implying that management shouldn’t have any quantitative measures and should only be qualitative?

Many managers would do a lot better this way. They'd still make stuff up, but would at least be forced to admit it.

You realize that you just reiterated the same point I made in the OP, right?

In my experience, there is no good solution long term except changing the metrics themselves every so often. When new metrics come in, as long as they are not totally boneheaded, they improve things. Then people start learn to start gaming them and some of the more sociopathic folks start doing so, then others copy by example and soon enough the metric is useless at best or detrimental at worst and it is time to move to a new metric.

It helps to have someone with a hacker mindset think about the metric being designed so the obvious ways in which it could be games are taken care of and their own metrics/incentives are aligned with the company goal.

Goodhart's law is always in effect. It can't be solved because it's not a problem, it's a fact of nature with annoying implications. It's the echo of the observation that efficiency is fitness as its consequences ripple from the lowest levels of reality through systems made of people.

You can make an engine as effective as the laws of physics let you, but you can't solve the limits of thermodynamics. You can only do your best within them. Same with this, for maybe the same reason.

Would adult developers not have made sure they had enough automated tests?

It probably depends whether they had been given specific instructions that directly conflicted with that.

And it also depends on whether they're given a timeslot for that and/or incentivized for it. Automated tests need times to maintain, especially if they're some changes on flow / specs, tests need to follow.

I scrap all incentivized metrics when working on something urgent (important and soon), which is often the case. If the metrics somehow incentivized, we'll start gaming it.

Now if a dev has part on production support and automated tests are purposed to reduce the workload for support then it has time slots for that, I bet everyone will start doing it.

If a civil engineer is given specific instructions to make an unsafe bridge, that engineer does not obey those instructions. I think adult developers should behave similarly.

The analogy starts to break down. Most software is less mission-critical than the structural integrity of a bridge. Meaning the consequences for failure are probably annoyance rather than risk of death. Not always. I would imagine the software for nuclear reactor or aircraft controls is in a different category, but most software is not bridges.

Okay, but if developers decide that then at what point do you say it's okay to not treat them like adults?

If you didn't have enough tests you weren't acting like adults. Why should he treat you like adults?

Maybe you are jumping to a conclusion too quickly.

How do you know what was really going on?

"He created a requirement that every developer commit two new tests to the code base every workday" seem a stupid requirement if you do not control the quality of the tests.

The same big corporation I wrote above had a goal of 80% code coverage reported on dashboards.

I saw people writing tests just to run lines of code, without effectively testing anything.

Others people were "smarter" and completely excluded folders and modules in the codebase with low coverage from coverage testing.

Code coverage percentage numbers on a dashboard are a risky business. They can give you a false sense of confidence. Because you can have 100% code coverage and be plagued by multitude of bugs if you do not test what the code is supposed to do.

Code coverage helps to see where you have untested code and if it is very low (ex: less 50%) tells you that you need more tests. An high code coverage percentage is desirable but should not be a target.

The real problem is again the culture.

A culture where it is ok to have critical parts of the code not being tested. A large part of the solution here is helping people to understand the consequences of low code coverage. For example collecting experiences and during retrospectives point out where tests saved the day or how a test may have saved the day so people can see how test may save them a lot of frustration.

But again, when you give people a target and it is the only thing they care about, people find a way to hit it.

He said it himself.

> When I worked at a FAANG ~15 years ago, a new VP came in and heard, correctly, that our group didn't have enough automated tests.

There are a thousand reasons why reasonable people might have found themselves in that position. Maybe they inherited a code base after an acquisition or from some outside consultancy who didn't do a great job. Maybe management made a rational business decision to ship something that would make enough money to keep the company going and knowingly took on the tech debt that they would then have some chance of fixing before the company failed. Maybe it actually had very high numbers from coverage tools but then someone realised that a relatively complex part of the code still wasn't being tested very thoroughly.

If a team has identified a weakness in testing and transparently reported it, presumably with the intention of making it better, then why would we assume that setting arbitrary targets based on some metric with no direct connection to the real problem would help them do that?

had to mention https://fs.blog/chestertons-fence/

if team does not have automated test, but still manages to deliver working software - maybe tests are not adding as much value as VP thinks?

the most important is feature delivery, and integration test, not automated unit test where you test getters and setters with mock dependencies - absolutely useless busywork

Tests aren't exclusively about asserting current behavior -- they also help you determine drift over time and explicitly mention the implicit invariants that people are assuming.

This might be relevant if the original comment didn't say "correctly".

Also "not testing a lot" is not a chesterton's fence. "not testing a lot" can't be load-bearing.

Chesterson's fence isn't saying that the fence/test isn't necessary. It's saying you need to take the time to understand the broader context rather than take a knee-jerk assumption. To be more clear, just because developers don't see the need for better testing, doesn't mean more testing isn't needed. But it may indicate the VP didn't doing a good job of relating why, which leads to the gamesmanship shown in the story.

Schedule isn't always the most important thing either. It's possible delivery the software may just mean you've been rolling the dice and getting lucky. The Boeing 737MAX scenario gives a concrete example of where delivery was paramount. It's a cognitive bias to assume that "since nothing bad has happened yet, it must mean it's good practice"

Without tests and instrumentation you won't even know if it's not working.

> The real problem is again the culture.

The culture lead to fake tests instead of adding tests that were legitimately lacking.

Is that so different from saying they weren't acting like adults?

The phrasing could be called dismissive but I give that a pass because it was mimicking the phrasing from the post it replied to. The underlying sentiment doesn't seem wrong to me.

> Code coverage percentage numbers on a dashboard are a risky business. They can give you a false sense of confidence. Because you can have 100% code coverage and be plagued by multitude of bugs if you do not test what the code is supposed to do.

Or, conversly, I've been in charge by really awkwardly testable code.. which ends up being really reliable. Plugin loading, config loading (this was before you spring boot'ed everything in java). We had almost no tests in that context, because testing the edge cases there would've been a real mess.

But at the same time, if we messed up, no dev environment and no test environment would work anymore at all, and we would know. Very quickly. From a lot of sides, with a lot of anger in there. So we were fine.

Need some tests for those tests!

Insufficient test coverage doesn't necessarily mean lack of self-discipline. It can also stem from project management issues (too much focus on features/too little time given for test writing).

An adult would have started to write the tests themselves so they'd understand what was going on around them. You don't just frown at people and hope for the best.

Accountability is a big part of leadership, though. The anecdote basically just says the VP used the wrong tool for accountability, not that "adults" shouldn't be held accountable.

I think what was missing here was lack of developer buy-in into the actual changes implemented, and making sure that they were reasonable and sustainable. Sounds to me like a blanket mandate was handed out without buy-in and also wasn't achievable, and the developers felt they had to work around it to get their real jobs done.

I agree. At the very least, it seems like he didn't communicate the "why". It certainly wasn't "to make as many tests as possible". I suspect the developers knew that, which is why is also a little unprofessional on their part to treat it like that was the goal.

I think the bigger problem here was inappropriate expectations: "two tests a day". That's not a reasonable way to increase test coverage. And so the developers quite reasonably just tried to minimise the time spent on it.

>Number of unit tests isn't the best proxy for that goal…

However, I don’t think mindlessly creating tests is acting in good faith. It’s bordering on malicious compliance. I don’t they were thinking they can just knock out that metric so they can otherwise create better test coverage. (The OP conceded their coverage wasn’t good). Better employees would work to create a better understanding/goal.

Malicious compliance is exactly what you get when people think your target is stupid and you put some automated, non-negotiable measurement in place.

If I was a developer there, I'd totally started adding those generated tests. I have a job to do (ship products) and you put in some stupid requirements which actually interfere with it (since my time is limited I can either work on tests or my daily tasks like developing new features or fixing bugs), but we both know that if my primary job suffers, I'll pay for it. So the best solution, from my point of view, is the one that takes that requirement away and lets me go on actually working.

When we had a similar problem in a previous company, we just created an epic, assigned a couple of people to it and have them churning out tickets for specific improvements, like "Class X has a coverage of Y on this method, add tests for the missing execution branches", which were clear, non-generic and fully integrated in our flow. If anybody complained about our velocity or whatever, we could show them the full trail which lead us to choose to work on that ticket and how much we spent on it. The coverage issue got solved in less than a month.

>If I was a developer there, I'd totally started adding those generated tests.

If I were a manager there, I probably wouldn’t hire you. You want people who are actively solving problems that matter, not just automatons beating their chest about how stupid everyone else is while they add to existing problems.

If I was a dev there, I certainly wouldn't be approving those PRs either.

But if the devs at the org all (or even substantially) tend towards malicious compliance, that's a sign that something has gone wrong, relations-wise

Agree. That’s what I mean when I say it’s more indicative of cultural issues.

I you were a manager there and would approve that metric, no worries, I'd manage to fly it past you.

Any smart manager, having to deal with this kind of policy, would either push back or approve any way to game it and then get the work done. But I doubt that a company which allows this kind of BS can retain smart managers for more than a couple of months.

If you read any of my posts on this thread, it’s pretty obvious I don’t agree with the managers approach. But I also don’t agree that the devs are doing the right thing either.

It’s telling that you show such dichotomous and defensive thinking.

So you disapprove of the decision, but would have enforced it in the most asinine way at the expense of actual productivity.

I just hope to never work with you and, especially, never use anything you helped building.

What made you draw that conclusion?

I made the point that the metric used (raw number of tests) is bad a bad way to enforce a good goal (higher code quality). I also made the point that metrics aren’t inherently bad, but they have to be chosen judiciously.

You seemed to take those two points and extrapolate an entirely different story and motives that, frankly, reads as a bit unhinged. So i also hope we don’t cross paths, because in safety critical code development where I come from where bad practices and toxic teammates can kill people.

> Without an outstanding company culture, most KPIs are almost useless.

Also, with an outstanding company culture, KPIs aren't really necessary.

So, when would they be useful?

I'm not as negative on KPIs as the previous line suggests though. They can be useful to shape direction when used carefully. But don't make them too long-lived, discard and create new ones as soon as they become gameable.

Yep, I worked at a place that was focused on everyone completing 100% of their jira tickets each sprint, just to get the metrics up. You didn't have to actually finish, it just had to look like you did to the bean counters.

If end of sprint came and you weren't done, the manager would close out the ticket, then reopen another similar one named "Module phase 2" or something similar for next sprint. One guy was an expert at gaming the system, and his ticket got closed and opened anew for about 3 or 4 sprints.

> Learnings? B and C players with questionable ethics screw companies quite rapidly.

No one should be surprised when employees respond to incentives, and blaming them seems a clear indicator of managerial failure: failure to tend to morale, failure to reward actually useful behavior, failure to articulate a vision.

Fire those folks and move on. If you're a subordinate and your leaders are not firing those folks, quit and move on.

Gameable KPIs offer windows into the souls of your colleagues.

Some examples of incrementally delivering tech debt and communicating it to stakeholders:

"This week we found the root cause of why operation X sometimes fails - it's a slow database query which we plan to fix next week. For those interested, here's a command-line demo of the issue."

"With 60 pull requests being submitted per week, and each one triggering a 12 minute automated test run, we were wasting a quite a bit of developer resources. This week we brought that time down to 4 minutes. For those interested, here's how we parallelised the tests."

"Remember how the last accounting feature broke a lot of different parts of the system and it took 4 extra weeks to fix? This week we migrated 4 out of 18 core accounting functions to a service completely separate from our main code base. Once the remaining 14 are moved over during the next three weeks, accounting features can be built and tested independently without affecting the main system."

When you give people a target and it is the ONLY thing they care about, people find a way to hit it.

So be careful what you measure and you reward.

For every company cash flow and profits is undoubtedly the most important metric. It is almost impossible to argue that maximize those numbers should be a goal.

At the same time when that become the ONLY target that matters, the consequences are dreadful.

At least in US, that is how we ended up with appliances that only last a small fraction of time that used to last 40 years ago.

And even worse it is how we ended up with the food industry creating more and more addicting foods resulting in 70% of the population be obese. And it is how we ended up with a heath system that cost multiples of any other country in the world, that, instead of healing people for good, make them "less sick" addicting them to a few pills for the rest of their life. Because there is no money to be made with a healthy person.

When you build KPIs, make sure you "think a few moves ahead" and you put other correcting metrics and checks in place. At least make sure who establish the metrics is aware of the possible shortcomings and correct them in a timely manner.

> For every company cash flow and profits are undoubtedly the most important metric. It is almost impossible to argue that maximize those numbers should NOT be a goal.

Except for VC backed startups. Actually, there are a lot of exceptions. But those mostly revolve around caveats surrounding riskiness and timelines.