<![CDATA[Possibly controversial take....]]>Possibly controversial take....

Software systems need clear, cohesive, continuous ownership/accountability. This applies to:
* running applications that require operational support
* software libraries and frameworks that are "merely" used by other applications
* company internal apps, OSS libraries, and everything in between

If there isn't a specific team, led by a specific person, owning the system, then there is an accountability problem. Things will go wrong. Fingers will point.

]]>https://board.circlewithadot.net/topic/09e87bf4-f578-4d9b-b19d-9a1753050d7c/possibly-controversial-take....RSS for NodeFri, 15 May 2026 05:06:32 GMTFri, 17 Apr 2026 15:46:48 GMT60<![CDATA[Reply to Possibly controversial take.... on Fri, 17 Apr 2026 16:31:17 GMT]]>This is not to say that it's impossible for this to work. But it is fighting human nature every step of the way. Refusing to define organizational structure, leadership, accountability, and governance only ensures that either there will be infighting, or invisible shadow versions of these structures will evolve. And shadow structures can't be effectively managed for purposes of alignment and efficiency. They are ripe for subversion by private interests.

]]>https://board.circlewithadot.net/post/https://mstdn.social/users/cammerman/statuses/116420999752007908https://board.circlewithadot.net/post/https://mstdn.social/users/cammerman/statuses/116420999752007908Fri, 17 Apr 2026 16:31:17 GMT<![CDATA[Reply to Possibly controversial take.... on Fri, 17 Apr 2026 16:28:32 GMT]]>I state this because in my experience not only is it common to see a coincidental lack of ownership, but also *intentional* lack of ownership.

There are people who don't like the idea of a software system having a "boss" or someone "in charge," and they think they can avoid this through collective ownership.

There are also companies that think they can avoid "silos" through shared ownership.

Both of these are misguided, and willfully ignorant of the nature of humans working in groups.

]]>https://board.circlewithadot.net/post/https://mstdn.social/users/cammerman/statuses/116420988914615057https://board.circlewithadot.net/post/https://mstdn.social/users/cammerman/statuses/116420988914615057Fri, 17 Apr 2026 16:28:32 GMT<![CDATA[Reply to Possibly controversial take.... on Fri, 17 Apr 2026 16:05:53 GMT]]>@DoodleDonut Absolutely. It's why the analogy to addictive drugs is so apt. The more you use it, the more you need to use it.

]]>https://board.circlewithadot.net/post/https://mstdn.social/users/cammerman/statuses/116420899863510938https://board.circlewithadot.net/post/https://mstdn.social/users/cammerman/statuses/116420899863510938Fri, 17 Apr 2026 16:05:53 GMT<![CDATA[Reply to Possibly controversial take.... on Fri, 17 Apr 2026 16:03:23 GMT]]>@cammerman I'm seeing the writing on the wall with this currently. A higher-up has been using Claude extensively to create an entire, complex project. They do know how to code well, relatively-speaking, but admit that they don't even read the code anymore. Instead they've built an elaborate scaffold of processes for Claude to follow, and extensive testing. It's impressive, but also frustratingly wasteful and short-sighted.

Part of me wants it to blow up spectacularly. The annoying thing is...if I were asked to contribute when this project was being started, I probably would have really enjoyed designing things. Instead, now it's a big black box of AI-generated code that is hard to understand and make meaningful contributions to...unless you also use Claude, which I have, and it was miserable.

So to your point -- when software devs actually *know* a codebase, there's zero friction to making changes. Anthropic is basically selling a solution to a problem they encourage people to make.

]]>https://board.circlewithadot.net/post/https://equestria.social/users/DoodleDonut/statuses/116420890038056906https://board.circlewithadot.net/post/https://equestria.social/users/DoodleDonut/statuses/116420890038056906Fri, 17 Apr 2026 16:03:23 GMT