From: cross@spitfire.i.gajendra.net
In article <109fr04$2n3qp$1@dont-email.me>,
Arne Vajhøj wrote:
>On 8/29/2025 10:33 PM, Dan Cross wrote:
>> In article <68b2549f$0$718$14726298@news.sunsite.dk>,
>> Arne Vajhøj wrote:
>>> On 8/29/2025 9:24 AM, Dan Cross wrote:
>>>> In article ,
>>>> bill wrote:
>>>>> Which is why I always preferred working for people with well defined
>>>>> local coding (and comment) standards. And, yes, I have worked for both.
>>>>
>>>> Yup, though this doesn't _really_ address the question.
>>>>
>>>> But yes: having a locally agreed upon style for such things is a
>>>> _huge_ boon for maintainability, particularly across a large
>>>> codebase. Sure, it's fun to belly up to the virtual bar and
>>>> debate the relative merits of different styles on USENET,
>>>> complete with contrived examples for or against different
>>>> conventions. But the reality is that if one is consistent
>>>> within a code base, it doesn't really matter all that much;
>>>> competent programmers will absorb the rules in a matter of days
>>>> or weeks.
>>>
>>> Yes.
>>>
>>>> The issue is that someone has to define the style and then
>>>> mandate its use, and it has to be enforced through rigorous
>>>> review and automated tooling. Given a sufficiently large group
>>>> of users, not everyone is going to agree with every rule; the
>>>> trick is in getting them to follow those rules regardless.
>>>
>>> It does not take that much to get coding conventions
>>> followed.
>>
>> Statements like this beg the question, what is the largest
>> project you have worked on, and with how many other engineers?
>> I am asking sincerely, by the way; that's not a dig.
> >
>> I once worked in a, at the time, 2BLOC monorepo with ca O(10^5)
>> programmers working in it concurrently in ~20 engineering
>> offices spread across the globe.
>
>Some small some big.
>
>Not quite as big as that though.
That's very vague.
>But the important question is not the size of the org.
>
>The important question is the commitment of senior management
>to enforce governance.
You're saying something close to what I am, which as a reminder
that this is really predicated on the organizational culture and
automation. But you seem intent to focus on this "senior
management" thing as the only thing that matters while making
vague assertions that it is "easy" as a result. It is not. It
is _hard work_ to build an engineering culture that makes this a
core value.
>> A tiny subproject within that was ~1MLOC split between about 500
>> KLOC in C++, and the other 500 KLOC in Common Lisp; HC was
>> around 20 FTEs mostly in a single office.
>>
>> The local style guide mandated that the maximum line lenth in
>> Lisp was 100 characters; I counted and estimated that at least
>> 20% of lines had more than 110 characters.
>>
>> That project came through an acquisition, and the code was
>> inherited. On the other hand, the rest of the organization had
>> _very_ rigorous code style rules for various languages (five
>> officially supported languages, and a dozen or so other,
>> unofficially supported languages) and gated integration
>> verifying compliance with those rules through both review and
>> automatic tooling. In that code base, style violations were
>> exceedingly rare.
>
>> But this is the difference between making something a strong
>> part of the organization's cultural norms and supporting it with
>> tooling and just wishing the problem away.
>
>Wishing does not solve anything.
No one said that it does. You'll note I said that it requires
enculturation and automation to do at scale. And it does.
>But leadership does.
...and tooling. And culture. All of which can flow from
leadership, but in Google's case it came from the ground up, and
on multiple fronts. The style guides, and then for example unit
testing, which was absolutely grass-roots driven by engineers.
There was even an internal group called the "test mercenaries"
that went around working with other teams, teaching them how to
leveral unit tests, building internal CI frameworks that worked
with Google's monorepo and build system, etc.
>The CTO want the standard followed.
All stick no carrot? Wrong.
>All supervisors get a goal in their MBO/WG/whatever
>to implement review minimum X% of code, ticket
>deviations and ensure they get fixed.
>
>Then do it. Nobody will want to mess up their
>bonus/raise/promotion/stackranking/whatever
>for that.
>
>Developers get the stuff reviewed. They get a ticket
>to fix it in that code and other code. After one or
>two times they make sure that there is no deviations -
>easier to just do it right the first time than to
>have to do it later.
Name one organization where you've seen that happen. Give a
real world example.
>>> If >5% of code is reviewed and not following coding
>>> convention get flagged and the guilty get asked to fix
>>> the code *and* other code that has same problem, then
>>> in a few months everyone is following. The risk of
>>> non compliance eventually being detected and the hassle
>>> of doing the fixes makes it easier to do the right
>>> thing the first time.
>>
>> That's cute, until managers step in and tell you to igore all of
>> that, because they've got a customer breathing down their neck
>> to get a feature they need into production. It also shows a
>> distinct lack of respect for your engineers.
>
>Those tickets just get handled similar to any other tickets
>not making it for the release.
>
>They go into the todo-list/backlog/whatever.
>
>Totally standard process.
Or you provide an automated tool that people can configure to
work with common editors so that their code is automatically
formatted on save, and then you build that into the CI process
so that violations are flagged on review, and you gate
integration on resolving this problems _at review time_.
THAT is a totally standard process.
>> The point is that you really need to inculctate respect for the
>> value that comes from rigorous adherence to those rules, and
>> support it with tooling so that they are easy to comply with
>> (and there are meaningful consequences for igoring them---like
>> your change just can't be submitted). Otherwise, they will just
>> be ignored, and attempts to force them by making people do a
>> bunch of grunt work if they're caught violating one will
>> backfire.
>>
>> The "culture of fear" approach that you and Bill both seem to be
>> advocating simply does not scale, especially once it runs
>> headlong into the reality of the business considerations that
>> come with taking engineer time to do a bunch of busy work to
>> fix something that somebody else did.
>
>It is how businesses work.
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
