-2000 Lines of Code (2007)
folklore.org
folklore.org
>In the PBS TV series based on Bob Cringely's Accidental Empires, there is a sequence where Steve Ballmer describes the experience of co-developing OS/2 with IBM, how the whole thing became a fantastic clash of corporate culture, with Microsoft having the small-company attitude of getting things done, and IBM being focused on internal measures primarily KLoCs, that is thousands of lines of code as a measure of programmer productivity. "All they cared about," raves Ballmer, "was KLoCs and KLoCs and KLoCs." IBM, apparently, did not care whether the code was any good as long as there was a lot of it.
Those of us who knew better treated the "celebration" as a wake.
I will never forget the story[1] of a Microsoft developer rewriting a piece of IBM code that had 33 thousand characters, after rewrite ... 220. This generated a war because MS's work was... negative.
[1] https://archive.org/details/bigbluesunmaking00carr/page/4/mo... page 101
For example, if quality is your goal, then the metric you give your devs is "number and severity of bug reports coming in from customers". If unsatisfied feature requests are part of that number, then the devs have to strike a balance between churning out features and preventing bugs (and fixing discovered ones).
Obviously your customer support needs a different metric.
Bug count metrics incentives "don't touch anything" and coding with feuture flags and globals to limit the scope of change and circumvent the architecture.
Like, just don't do metrics and have the management actually review the work of their subordinates if that is important to follow up on. Actual management can't be compressed to a acting on some scalar values.
https://news.ycombinator.com/item?id=33483165 (2022)
https://news.ycombinator.com/item?id=26387179 (2021)
https://news.ycombinator.com/item?id=10734815 (2015)
https://news.ycombinator.com/item?id=7516671 (2014)
https://news.ycombinator.com/item?id=4040082 (2012)
No, not because I had some brilliant insight but for the simple assumption that my predecessor may not have been aware of how to write functions or use parameters to supply variable data to the SQL query. They had literally written the same SQL statement inline with a couple of changed values in each SQL call.
I just rewrote the code making the SQL call as a function call with bind variables as parameters into the function. All the replicated inline code was replaced with the function being called in a loop with the changed bind values supplied from an array.
This is not only impossible to measure as a numerical metric but also makes you enemies. Kudos to those who dare to do that anyway.
Which is why I teach new people to have that loop in your head and not start pounding the keyboard at high velocity. The people who find programming to be akin to fast typing show very interesting equivalence with LLMs; fully write/remove/write/remove etc of not very well written code.
For around 1/2 the information requests that came through the department (always very important, we need the info now, it will save/make big dollars) the obvious answer was "Work it out from the info you already have. You've got a calculator and spreadsheet - would you like a pencil?"
Better to avoid the system handling X than having multiple special cases bulking up the systems, most of which only get used once in a blue moon. No one knows the special cases/programs are there, or what actually do. Even if well documented, no one spends the time required to know what's available. So most of those special features are actually waste of time.
If the product is "finished" then it would probably be equal or better (otherwise the negative LOC change wouldn't make it to prod).
But most products are ever evolving (that's why we have the luxury of remaining on the same project for years), so just negative contributions will invariably not add anything.
This isn't a good measure of productivity, especially not in isolation, but it's a reasonable napkin-math metric of change. A developer with a high ΔSLOC count may or may not be more productive than a peer who has a week or two of no ΔSLOC at all, depending on what that peer is up to, but the first of these is definitely changing the codebase more than the second, during the measured time span.
I'm working on some java 8 cide that was written by folks still living in java 1.4 land, lots of opportunities there to reduce 20 lines into 3 (plus those devs kinda insisted on doing things in painful and unnecessary ways). In parallel, I'm working on a Greenfield project. Even on the Greenfield, there are times when negative code added is good. Not all programmer activities are equal
It's like measuring gas consumption during emergency braking, during acceleration, and during normal highway cruising. Sometimes it firs, or kinda fits, other times it's just the wrong metric. Programming is not a homogeneous activity
ΔSLOC is just a metric, and what it measures is change to the codebase. Yes, some changes are very important, and others nearly trivial, so it's quantitive because a qualitative metric is a contradiction.
It certainly means different things in different contexts, if it's even meaningful at all. My claim is that +SLOC is entirely meaningless outside of the tautology that it measures what it is, where ΔSLOC is in fact informative about change to the software, albeit not perfectly so.
My hope is to convey more texture here, that programming is more than just one thing. EG: "Today I was mostly debugging". That could have its own measures. I think in large part the measures of programming productivity are often too reductive, the measure is incomplete or tries to measure "programming" rather than its _many_ distinct sub-activities.
Metrics that are team level dashboards and not shared outside of the team are different from pay and promotion incentivized metrics. The same metric can have very different behavioral outcomes between the two scenarios
For example, the perennial idea of replacing all the software engineers and their arcane code-text with product-managers drawing some special diagrams or flowcharts for "low"/"no"-code results.
And don't forget, these guys had to fit everything, including those -2000 lines of code (assembler code) into 64kbytes of ROM - there was intense pressure to make stuff smaller
[1] https://computerhistory.org/blog/the-lisa-apples-most-influe...
[2] https://computerhistory.org/blog/macpaint-and-quickdraw-sour...
If you follow that second link you'll find a zip file with quickdraw source in it, you'll find that while there is a little pascal (.p files) most of the core is assembler (.a files)
Along the way he kept having to both invent new ways for user interfaces to work, and new ways to write software to solve for them. There's a kind of synergy that emerged out of the fact that he was optimizing both for 'can be done quickly in the hardware available on the Mac', and 'provides a great user experience', which means that his fingerprints are all over the aesthetic of the old black and white Mac. That dither style is another example of that kind of marriage of algorithmic genius and aesthetic sensibility.
And it shows up in things like the 'marching ants' selection boundary (https://en.wikipedia.org/wiki/Marching_ants). Or the way lots of user feedback in the classic Mac UI comes in the form of inverting pixels (text selection, menu highlighting, the way buttons appear during a mouse-down, the boundary of a window while it's being dragged), because drawing over something in XOR mode was a great way to generate that effect. The way he approached putting these tools together in QuickDraw also had the effect of things like his famous conversation with Steve Jobs about rounded rectangles (https://www.folklore.org/Round_Rects_Are_Everywhere.html) manifesting as it being as easy to draw a rounded rectangle as a square one in QuickDraw, which led to them showing up everywhere in the operating system.
The success of the Mac UI was not just that it looked good; it was in large parts that Bill Atkinson made a really cleaver, small set of tools that made making things that looked good easy to make.
Susan Kare's amazing icons wouldn't be nearly as fondly remembered if Bill hadn't built the tools that made it easy to drop 32x32 pixel masked bitmaps into the UI and invert them when you clicked on them.
I believe he managed to work on patents only in the morning..
if cond { ... return; } ...
into
if cond { ... return; } else { .... }
But that's not comprehensive either.
Of course what companies should really be incentivizing is well written code that is easy to maintain and extend, not bloated cut-n-paste garbage.
Also related to Enshittification (see fecal matter), the platform shifts, no longer prioritizes quality, and instead shifts to whatever "well written" is defined as.
LLM's and especially online song choice algorithms have a heavy dose of this. "Make whatever pop music says is 'well written'" You have included all the keywords necessary to SEO your billboard submission.
How small a function should be? https://youtu.be/rXjf8eiGsSI
Pretty sure its not a T-800 Terminator or smoking pot like Bob Marley reference.
Also, totally feel like an LLM doing the %chance this word game.
Wouldn't the really agile thing be to get rid of alliances and chairmen in charge of telling people how to develop software?
The hard part is measuring the effectiveness of people whose output is realized in the future, not today.
Unemployed guy who wakes up at 11 a.m. every day: "I must be a genius!"
Barba non facit philosophum: a beard doesn't make one a philosopher.
― Carl Sagan
My own experience was changing a 10K line module with a template in one page. Put some angle-brackets in about 100 references which left a net -9900 LOC
Code is a means to an end, and an expensive one at that. The best code is the code never written. Our job is to solve problems, not to write code.
You can use LOC as a crude measure of progress, in the same way as tons of concrete used is a crude measure of progress when building a skyscraper.
LoC is about as good a measure of a system quality as weight is for an aircraft project.
This is a very good an analogy. A plane has to weigh something, but the absurdity of measuring how much progress you’ve made building a plane by how much weight you’ve added is immediately obvious.
I am also not a civil engineer but I can think of a lot of ways to add concrete to a skyscraper in ways that are somewhere between nonhelpful and burdensome.
“Measuring programming progress by lines of code is like measuring aircraft building progress by weight.” ― Bill Gates
Of course, you also don't make the skyscraper better by indefinitely adding concrete. A balance must be found with the right amount to be load bearing but not too much. Just like code.
Compare for example a building made of stacked stone, brick, concrete, or modular carbon sheets on rebar
Another example, 100 hotel rooms, rearrange the layout and it's 101 things to do.
The analogies still fail, software updates are more akin to welding an airplane on to a car attached to a subway train. It's less, oh, we need to rework these weldzhere, it's often trying to make the software do something that is radically different. Like inserting a romance chapter into a mystery novel that starts as a chemistry how-to
LLMs solve the problem of "we don't have enough code, so let's generate low-quality code faster than ever", which, to a first approximation, is not actually the problem that anyone has; the problem we have is that we don't have the right code, and the code that we do have is already shit.
But at least managers will be happy that their reports are now checking in +100,000 LoC a day. What could possibly go wrong?
My job is what my employers pays me to do. If my employer agrees with that sentiment then it is. If I'm volunteering on open source, I can do my best, but if my employers rewards lines of code, then I produce LOC. Of course, picking a better employer factors in there somewhere.
That said, there are other equally bad metrics that are in current use.
But if this happens more than rarely, you either find a new job or stay and live with the fact that you've become a second rate programmer in a second rate company.
which is only possible because he's so important.
imagine doing this as a stack-ranked IC in an org like AWS.
The old days of a software as an artisanal craft is long over imho.
Reading comments like yours, I guess I should value my work environment more.
Ostensibly it appeared to be tuned to be racist.
Maybe Google encourages people to speak up but also has a culture of racism?
Especially because here we're talking about someone whose performance and contributions were very clear to everyone. Otherwise, he might have been seen like an underperformer by managers.
Protection from retaliation and group negotiation on working conditions are brilliant for people who aren't as "important" as Bill.
Abusive boss, normalized unpaid overtime, compensation based heavily on stock options, pay and promotions being based on merit and not on seniority and time spent in a company.
In corporate or government software work, sure. But there are no guilds anywhere in those organizations... unless you count the upper executives.
You might not get paid for it, but the artisanal craft of software is alive and well in free and open source software around the world. Tons of those projects get posted to HN. An app can be a home cooked meal and all that jazz. Lots of open source has been corportized too, but many are closer to an artisanal craft guild than modern corporate software work.
And if it is your startup, you can write code however you want.
aka, you are not economically valued, and in order to be artisanal, you have to sacrifice monetary gains to achieve it.
> if it is your startup, you can write code however you want.
yes that is true, but a startup is much more than just code. it's a business - with all of the extra work that entails.
Sometimes that's good, sometimes it isn't. But I think we can count relieving the developers of the drudgery of form-filling as an unalloyed good.
The point is that there are management styles out there that tries to objectively measure a software engineer's performance (poorly). And unless you are someone with high clout in the organization, you are subjected to it regardless of whether you like it, it making sense, or it being used to control the employees (politics).
Simply work for a smaller company..
I have had one good manager though, and it's pretty obvious what made them great. First is they listen to what problems you have and actually help you do your best work. Secondly, they protect you from the other bad leaders at the company. Thirdly, they work too hard.
Or maybe it is an availability thing? My personal experience is I'm much more motivated to work If my manager is highly available from early morning to late evening.
On the plus side I replaced an O(n²) algorithm with a faster one in the very next commit. Needed to get rid of the ninety copies of the same bad idiom first.
Or a sufficiently efficient "extract to method" on a decent IDE, that notices the different occurrences even with renamed variables.
Unless those lines of code were subtly edited all over the place and needed careful and subtly different replace for each occurrence, or at last review because that's what's truly evil with duplicated code. It's forks that diverged to maintain N times in your codebase.
Why? Didn't you know the shortcut `d600d`? /s
Can feel you right there.
Begrudgingly I hope...
If you replaced 4000LoC with a regex that regex scares me...
I wish I could write such a monstrosity though :)
Or you've completely missed the point of the article/story. The point is lines of code are almost meaningless. In this story the person saved 2k lines of code by rewriting a rendering engine, and use somehow think that's less than deleting a 45 k line jest snapshot.
I think there are parallels between Deutsch’s ideas about explanation and the concept of coincident vs inherent complexity
It is in fact the same phenomenon as treating +SLOC as a proxy for productivity. When everyone is rewarded for adding process, but it isn't anyone's job to remove it, a system inevitably ends up with too much process.
It does measure something, not necessary something useful but zero LOC indicates trouble.
If you work insanely hard solving a problem, you often end up with 0 loc + an incredible amount of understanding. If you slack off all day then spend an hour writing a bunch of sloppy code, you have way more loc than someone who worked all day to refine some simple clear performant code (which is then read 500 times before it's changed, hence the time is earned back with interest).
These scenarios don't have to happen for the disincentive to still affect the work people do; there's a continuous problem from the baseline to these extremes.
and that ideal manager has a much better and multidimensional idea of performance over time than commit rate.
the platonic ideal of manager isn't some kind of school marm whose primary concern is figuring out when people are slacking off
Agreed, and this includes managers reaching out to their reports.
> I fail to understand this model where 'blockers' are some kind of hidden disease that a manger needs to actively ferret out.
You're imputing an attitude to me which I neither hold nor intended to convey.
> in healthy organizations I've worked in..the whole notion of a blocker doesn't really exist.
Weird. The idea that a step in a process can't be completed before another step seems bedrock to me. It's always good to eliminate these dependencies when one can, but that isn't always possible.
> the platonic ideal of manager isn't some kind of school marm whose primary concern is figuring out when people are slacking off
Considering that should be obvious, since an ideal doesn't have negative qualities, I'm forced to conclude you're responding to a bunch of things I didn't say.
I’ve got to admit, I found this kind of _frustrating_ at the time, but if I’d insisted on writing something, anything, from the get-go, it would have been a complete disaster, and no-one would have thanked me for it.
It may indicate an employee with nothing to do, but in that situation would you prefer the employee did nothing, or started destroying the code base by adding KLOC of garbage to keep their manager happy and unsuspecting ?
(Now, mind you, I’m sure that lots of other ‘KPIs’ are nothing of the sort, either.)
It's just that you and they define "performance" differently. It's perverse incentives all the way down (or, perhaps, up).
Have you MET middle managers in the wild? As I said, most of these metrics are measured because they are easy, not because they are useful. The incentives at that level are to come up with some sort of metric and browbeat people into making it; the incentives for the browbeaten are then to make the number. Doesn't matter what the number means.
It only measures something loosely correlated with progress toward completion and only if you know what done looks like.
It is very informative for managers to take a periodic look at the number/frequency of commits from each engineer and their size, and from there dive into each commit and explore the denseness of the code, the cyclomatic complexity, and the overall nature of the commits.
This can reveal potential problem areas for the manager to investigate with the engineer. You might find that the engineer has very few, very small commits compared to their peers, and then upon looking at the actual code you may find that the code seems rather trivial. This would warrant a conversation. Why have they reported at every standup the last six months that they're stuck behind very tricky problems when the commit history shows only a couple of seemingly simple changes? Maybe the problem really was tricky, but maybe the engineer is struggling and doesn't realize it. So let's find out.
So while no one should be reduced to a simplistic LOC metric, and recognizing that more code can mean more bloat, we can't pretend that the amount of code that a developer writes is devoid of any meaning, as if it were just a random number.
That bug was left unfixed for months but now it's solved. Should I have received a talk because of that?
(Of course the commit would have had at least 10 LOC more, explaining the reasons and providing references to future devs/self)
Of course not.
But, if your commit history for last 6 months is just one or two of those one-line changes a month, that might hint that there’s a problem.
I believe that if you are a good manager, you would just need to look at what tickets get done during the sprint and that's it. If you complete your tickets and pass QA/UAT in 10 LOC, so be it. There is no need to micromanage.
A good manager should recognize that if a developer does nothing but annotate code with comments, and that's not what they're expected to be doing, there's a problem.
But there are people (I’ve seen this frequently) who constantly represent their work as having been “much more difficult than expected” but then you discover that they actually are struggling with what should be easy tasks, and looking at code (complexity and volume) is a data point. For me, more often than not, it serves as a confirmation of a problem I’ve started to suspect.
Joe is always the one in every standup saying the thing he's working isn't done yet because he's wrestling "one last tough bug." As a manager, you wonder if the technical problems are really that tough or if Joe is just struggling. Let's look at the commit history... yeah, something is off here, Joe has 1/10th the commits of his peers and they really don't seem more complex in any way, but look rather trivial. Time to talk to Joe and look at these commits together and see what's going on.
Is that really such a troubling proposition?
I guess I should be grateful for having a workplace that has sufficient understanding for the effort it takes to debug such issues.
I encourage you to look at the code produced by whoever you think is the top engineer in your team or company (and I'm talking only about the engineers whose job is still primarily hands-on coding, versus advising/mentoring/architecting etc). Now look at the code by that one person who you know isn't pulling their weight and who you think isn't getting much done. I'll wager that your top engineer is pumping out a ton of strong code, and the other one is a trickle.
This is bad, but it’s not the worst type of engineer. The worst engineers often have huge deltas and can kill companies singlehandedly.
If you're a manager and can't tell what your employees are doing, you're a terrible manager. Same reason they hate people working from home, they can't actually tell if someone's a good employee, they have no clue whether anyone is good at their job because they don't understand their job
1) A good manager needs to look at code to see what employees are actually doing. They can't just rely on the employees' verbal description.
2) One (correlated though not guaranteed) indicator that an engineer is struggling is when they are producing much less code than their peers or compared to any natural expectation of the role. Yes of course it's 100% that some bugs are super tricky and take a long time to find the magical one-liner fix. But statistically those are not common.
This is premised also on my belief that every engineer manager should be a very strong engineer themselves. This is common at most of the big tech companies.
The scalar of «amount of code that a developer writes» is «devoid of any meaning» outside frameworks of streamlining of such code (which would themselves not be a good idea, as you would in fact actually have classes of code, to be judged differently). The submitted specifies it was a case of a simple scalar field in a form.
Your argument is of course valid, but your conclusion disregards it. Outside a defined framework of quality adherence, the «amount of code» is «a random number».
The interesting part is all in the productivity (bulk of quality). That is the area that should be investigated - in both discussion and assessment.
And clearly, "amount of code produced" is a bad incentive, against quality. Aaaalways take care and beware of incentives.
A manager looking at the individual LOC contributions is looking into the wrong direction.
I eventually got called in and fixed it with a while loop and one function call inside of that loop. 4 lines in total, counting the brackets.
A very trivial change if you didn’t know why it was there, what impact it had on the system or how much it would have continued to cost in engineering hours if I hadn’t figured out what went wrong, why it went wrong and how to fix it.
I’ve spent a good chunk of my 15 years as a software developer as a pure “bug killer” and then you don’t really get to write that many lines of code, but the impact per line is big.
Every what?
But while every team member talks about the difficult bugs they’re facing, sometimes the actual code tells a different story and can reveal that a team member is struggling to get working code together in any reasonable amount of time.
Yes, having a chat between the team for fifteen minutes every day is in fact quite useful, believe it or not.
We're not talking about hour long waterfall-y management progress review meetings here.
You could use the same logic to claim that "issues and PRs are not useful" because the Linux devs use a mailing list and patches. I think that's obviously absurd, all that this example shows is that a mailing list and patches can be a useful way to develop programs. It says nothing about alternatives at all.
How do you know this? Have you done an exhaustive search?
For one example, are you quite certain that no part of any military ever does this?
What about every factory?
You are assuming (1) that standups are status updates, and (2) that they are scheduled by manager, and (3) for benefit of the manager.
In the last several teams I’ve managed, it’s the crew that has encouraged meeting daily, and in the standups they are mainly talking to each other. It’s where they cover hot topics and bugs for the day quickly, with the fluidity of spoken conversation instead of Slack, and also there’s a non-zero amount of friendly casual conversation.
Don’t force teams to have standups, but also don’t assume a team won’t like it.
If you ever move to management, you'll see that as lovely as it would be if every hands-on developer was an amazing and super-productive engineer writing high-quality code and delivering tons of value , the reality is that most teams have one or more people that are struggling and aren't getting much done, but aren't forthcoming about it. They'll represent their work as very challenging (which it is, to them), meanwhile others on the team are objectively better and faster at figuring out solutions and not getting stuck, and they understand the codebase better, and the architecture, and so on. The manager has a duty to spot when this is happening, and engage with the engineer immediately to figure out what's going on and try to help them.
Engineer managers should themselves be strong engineers (and in every company I've worked at, this has been the case up the senior leadership chain), so that they can form a realistic, fair, and reasonable assessment of whether there's a discrepancy between how an engineer represents their work, versus what is shown in the actual commit history.
What, and I mean this in the nicest way possible, the everliving fuck are you talking about?
Professionals do this constantly. Go sit in an ER and watch the hand off between shifts. Go see any serious manufacturing facility and see them review daily everything that happened the previous day. Go see an effective sales org in action.
The scrumbags may have ruined software, but that certainly isn’t the world.
You make your not entirely unreasonable points sound like the output of a zealot.
Why are there no laymen agile coaches at law firms, and no "today I did this, today I did that" breakfast meetings in finance, or in CS academia? Other professionals don't accept this kind of infantilization.
- a bugfix which takes ages to find and ends up being one or two lines of locally trivial code
- a senior who spends most of their day unblocking junior devs and keeping the team on track: 0 lines of code
- overzealous code formatters: lots of lines of code
- a junior writing an overly complicated mess of a solution to a problem that could be solved much more simply: ungodly amounts of code
- a developer talking to the client directly and finding out that problem that they're trying to solve is already solved by the product in a way that the client didn't think of, rather than immediately wasting company resources on a feature that's ultimately unnecessary (0 lines of code over lots of lines of code)
There is 0 correlation, none whatsoever, between lines of code committed by a dev and their value they provide to the business.
This is quite unlikely to be true. No correlation at all?
Especially if we shift to ΔSLOC rather than +SLOC, I don't believe that for a second.
You've made a good case that it's a bad proxy for productivity. It is. But there's no need to over-egg the pudding.
I once had a junior engineer who took maybe 4-6 weeks to fix an intermittent bug in dynamic lib loading. When he finally fixed it, the fix was <5 lines of code. But it was obvious that (1) the bug was insanely deep and hard to find, and (2) he did amazing kick-ass debugging to uncover it deep in Linux code. It was great work, and he was one of our top rising talents. But that's not the kind of cases that I'm talking about.
No, it's instead the engineer who gives the appearance that they're always doing tough work, but then the commit history shows that they're simply not. The person who says they're implementing a new data structure in the code, but really then take a month to replace a list with a dict in python, or whatever. This happens.
> a senior who spends most of their day unblocking junior devs and keeping the team on track: 0 lines of code
I'm not talking about them at all. I'm talking about people who aren't doing mentoring, advising, architecture, forward-looking design docs, etc.
> overzealous code formatters: lots of lines of code. A junior writing an overly complicated mess of a solution to a problem that could be solved much more simply: ungodly amounts of code
Yup, this happens. This is also something managers will learn by looking at code.
- a developer talking to the client directly and finding out that problem that they're trying to solve is already solved by the product in a way that the client didn't think of, rather than immediately wasting company resources on a feature that's ultimately unnecessary (0 lines of code over lots of lines of code)
Absolutely. The best way to get more work done is to figure out what work you don't have to do.
But if you have an engineer on your team make $200+K/year and they're not writing much code, nor writing design docs, nor advising other engineers, nor guiding the technical strategy, etc... if all the engineer does all day is "not wasting company resources" by doing very little whatsoever, you have a problem on your hands.
Imagine buying in software, against a specification. A fully detailed specification with tests both for logical correctness and performance. If there is a choice of vendors, at similar prices, one naturally chooses the package with fewer lines of code. The weight attached to LOC is negative.
The anecdote is interesting because it invites the following speculation. Question: How many extra data points, beyond LOC, does one need to manage a software project? Answer: Enough that the weight attached to LOC, given optimal use of the other information available, is negative.
what is your only goal - to maximize your teams contribution to the goals of the company. full stop. its not to stack rank your employees unless it serves that greater goal.
but you don't understand the domain. oh no. all you can do is develop a human relationship with the team. listen to them. you can't judge the quality of their work, but they can.
don't ask them to rank each other (I've seen this), but just be attentive. after not to much time you can really start to understand how people are helping the effort, and how they are undermining it. in broad terms, without understanding the gory details.
this is the only thing that works. everything else is just obfuscation.
You should consider working somewhere where management is deeply technical. At everywhere I've worked, the entire eng-management chain (up to CEO) fully understood the domain (as you put it), the state of the art, the key system architectures, and so on. The idea that an eng manager's role should be limited to "developing human relationships and being attentive", would simply not fly.
Eng managers need to be able to go into code, and they must be able to gauge the complexity of the work under them, or they'll be unable to spot the difference between someone aggressively chasing a nasty heisenbug for weeks, versus someone struggling for weeks to put together a basic block of working code.