From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: chad Newsgroups: gmane.emacs.devel Subject: Re: Recentish C-s M-y change Date: Fri, 1 Jan 2021 14:47:40 -0800 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000c75c3005b7de873e" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27628"; mail-complaints-to="usenet@ciao.gmane.io" To: EMACS development team Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jan 01 23:48:57 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kvTE8-00074A-Lq for ged-emacs-devel@m.gmane-mx.org; Fri, 01 Jan 2021 23:48:56 +0100 Original-Received: from localhost ([::1]:43716 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kvTE7-0004lB-O4 for ged-emacs-devel@m.gmane-mx.org; Fri, 01 Jan 2021 17:48:55 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40890) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kvTD9-00042b-BA for emacs-devel@gnu.org; Fri, 01 Jan 2021 17:47:55 -0500 Original-Received: from mail-yb1-xb30.google.com ([2607:f8b0:4864:20::b30]:44411) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kvTD7-0001gV-Jd for emacs-devel@gnu.org; Fri, 01 Jan 2021 17:47:55 -0500 Original-Received: by mail-yb1-xb30.google.com with SMTP id x2so20466451ybt.11 for ; Fri, 01 Jan 2021 14:47:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=/A1hwwhm+h199MOM/Od/zFhGkVGcR9XZ2DxmeVFgZXg=; b=O5rA2pms0QIfV4EFG/BYExvQ3He4HKxTSYT4aBg7/J+Ak+lxj754qSKOKYMsJMAaYt YSPholjmMNqUb964kXsP+Zoj16WT+5u/fBEUKq2wsFT6VNtG1NHn/RQjmXhXZkwbdx1T lbm6rKXkP9SQ11xqkvtOX4bLSqWi2Jl7DlH6B/e0XYiXmD1WKpYgyl9qKDd8WgpnNAqi ECBfFPX5msm6jlG2XhTK95khTdNXAShjQTuylLw4qZ4H4hvViTbtuWcNymqlHEXKMEiM Myr2jRqVsap8GqeisXrScX11op9PwwvtX5rvqaixLLZ3ZOksPbR7zCQ1S0tLyICqHgqC eZOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=/A1hwwhm+h199MOM/Od/zFhGkVGcR9XZ2DxmeVFgZXg=; b=FF85VsEmvyMT8Et7O5Y+xth6eFEmrOeNeLS1HxRCEI6CTndEaylbhK3Zd4pXtar+Ju RpHipKmiv4tB7Ulx/T5YquDLoxp1R7Lrfq15P7DOamEh5i8i5fId0+Kw5aTOIUyOa3w3 jKAEiYgpTW0svxs/h15zBYM6p4abh1abPldg4hq0V1urfd6ETqGa8eYSOAjMcST0Er/M Rr1doR6BEvv/Aq2UHJYvaHz1V1QY5reOl0qVyGzbPA2kPu1tKY+fiflAPw1kd6zj2GHs OhdPxov+HpUPcQsQFwFIn37qALg7pi3I/Ce02IWu4MfNfcCajpM7hzDjd/O8bCpHQFyn 9ZVw== X-Gm-Message-State: AOAM5324jrQTBPwGeOwgiqsSmyeOma2mTqaF8LnOEzj3KV9HgUshLMB8 WfV1VFyfkg78KsLswiMqBIK/yOV07ji3x8HuHa9AUdC0VqA= X-Google-Smtp-Source: ABdhPJxxpMJlKP4hnZWKatdb+s95AOP/E9uYJsMR+I9c7HS4j6KBHVGZS+UqJjbCsbIHqbO/pa6alWLKro7SVa2mamI= X-Received: by 2002:a25:8b:: with SMTP id 133mr94824770yba.513.1609541272164; Fri, 01 Jan 2021 14:47:52 -0800 (PST) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::b30; envelope-from=yandros@gmail.com; helo=mail-yb1-xb30.google.com X-Spam_score_int: -19 X-Spam_score: -2.0 X-Spam_bar: -- X-Spam_report: (-2.0 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, GAPPY_SUBJECT=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:262268 Archived-At: --000000000000c75c3005b7de873e Content-Type: text/plain; charset="UTF-8" I've removed the name from the following quote, because the topic I'm bringing up is not about that person, not even the context of "their" message, but simply and solely the sentiment quoted. On Fri, Jan 1, 2021 at 3:15 AM someone wrote: > it is not all that much to ask that changes to existing > behaviour is done by discussion first, in a small group to feel what > the reprecautions might be. > This might feel true, but both academics who study software engineering and people who manage software projects for large, medium, and small teams will all tell you that it's very rarely borne out by experiment. In practice, the sort of "must check first" approach to multi-person software creation leads to some combination of massive overhead, ossification, cover-your-ass behavior, and deteriorating team dynamics. It works in small, tightly-knit groups with a high degree of both on-topic and incidental interaction, and basically doesn't work otherwise*. In a widely distributed volunteer group like most multi-person free software communities, you either have a BDFL, you trust your developers to use their judgement (including occasionally being wrong and recovering), or your project atrophies. In this case, Lars was exactly right: > Here a developer > made a change, we tried it out for a time, I said "this is a bit > annoying", others agreed, and the change was reverted. This is how the > system should work. That said, it's fine for people to say something semantically like "I think we might be getting a little too loose with big changes on the bleeding edge. Maybe we should use feature branches more often?". It's possible that that's the exact sentiment that people are trying to express, but the realities of email lists creates a wide gulf between the above expression and "why are these things changed without doing some rudimentary query of users?". I hope this helps, and doesn't just add to the noise. ~Chad * I've seen this reported by people including researchers at MIT; at large companies like Amazon, Boeing, Google, IBM, and Microsoft; at medium-sized companies like Oracle (back when their software teams were medium-sized), Cygnus, and Red Hat, and at companies so small that nobody should recognize their names. If you're interested in the topic, I suggest Fred Brooks' _Mythical Man-Month_ as a baseline, and his _The Design of Design_ for a follow-up, as well as _Peopleware: Productive Projects and Teams_. (Caveat: it's been a while since I studied this, so there are probably more recent sources available.) --000000000000c75c3005b7de873e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've removed the name from the following quote, b= ecause the topic I'm bringing up is not about that person, not even the= context of "their" message, but simply and solely the sentiment = quoted.

On Fri, Jan 1, 2021 at 3:15 AM someone wrote:=
=C2=A0it is not= all that much to ask that changes to existing
behaviour is done by discussion first, in a small group to feel what
the reprecautions might be.

This might = feel true, but both academics who study software engineering and people who= manage software projects for large, medium, and small teams will all tell = you that it's very rarely borne out by experiment. In practice, the sor= t of "must check first" approach to multi-person software creatio= n leads to some combination of massive overhead, ossification, cover-your-a= ss behavior, and deteriorating team dynamics. It works in small, tightly-kn= it groups with a high degree=C2=A0of both on-topic and incidental interacti= on, and basically doesn't work otherwise*. In a widely distributed volu= nteer group like most multi-person free software communities, you either ha= ve a BDFL, you trust your developers to use their judgement (including occa= sionally being wrong and recovering), or your project atrophies.
=
In this case, Lars was exactly right:
Here a developer
made a change, we trie= d it out for a time, I said "this is a bit
annoying", others a= greed, and the change was reverted.=C2=A0 This is how the
system should = work.

That said, it's fine for people t= o say something semantically like "I think we might be getting a littl= e too loose with big changes on the bleeding edge. Maybe we should use feat= ure branches more often?". It's possible that that's the exact= sentiment that people are trying to express, but the realities of email li= sts creates a wide gulf between the above expression and "why are thes= e things changed without doing some rudimentary query of users?".

I hope this helps, and doesn't just add to the noi= se.
~Chad

* I've seen this reported = by people including researchers at MIT; at large companies like Amazon, Boe= ing, Google, IBM, and Microsoft; at medium-sized companies like Oracle (bac= k when their software teams were medium-sized), Cygnus, and Red Hat, and at= companies so small that nobody should recognize their names. If you're= interested in the topic, I suggest Fred Brooks' _Mythical Man-Month_ a= s a baseline, and his _The Design of Design_ for a follow-up, as well as _P= eopleware: Productive Projects and Teams_. (Caveat: it's been a while s= ince I studied this, so there are probably more recent sources available.)<= /div>
--000000000000c75c3005b7de873e--