From: arne@vajhoej.dk
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.
But the important question is not the size of the org.
The important question is the commitment of senior management
to enforce governance.
If that commitment is there, then it is matter of basic
management skills to get it implemented.
VP->Mgr->Dev
or:
EVP->SVP->VP->SrDir->Dir->PriMgr->SrMgr->Mgr->Dev
> 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.
But leadership does.
The CTO want the standard followed.
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.
>> 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.
> 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.
Developers are free to use whatever standard or lack
of standard in their hobby projects.
At work they do whatever the company want, because the
company is paying them to do that.
It is the only approach that scale.
Having everyone do what they believe is right does
not scale.
Arne
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
