What happened to hiring an architect?

The Wanderer wanderer at fastmail.fm
Fri Dec 16 20:00:38 UTC 2016

On 2016-12-16 at 09:11, Robert Kaiser wrote:

> The Wanderer schrieb:
>> What you need is a policy that all changes to user interactions
>> must be backwards compatible, and able to be "switched off" in some
>> way - whether by config option, or by add-on, or by userChrome
>> changes (preferably documented somewhere!), or almost any other
>> method. (The idea of "first-class addons" could easily help with
>> this; if you introduce the change to user interactions as a new
>> add-on which is present by default, and pull "the way it used to
>> work" out as a new add-on which can be swapped in for those who
>> want to switch back, that would seem to address the issue
>> entirely.)
> If you develop software yourself, you quickly find out that this is
> how software dies. It becomes unmaintainable or just doesn't adapt to
> the changing world around it and is superseded by younger software
> that doesn't come with that ballast from the past.

That's why I think the idea of "first-class addons" - and the idea of
having a relatively tiny core program, with first-class addons (some of
them shipped by default) providing much of the program's functionality -
is so promising; I think it holds the potential to address that problem.

Once the "old" behavior is split out into an addon, the main developers
don't need to continue maintaining that addon if they don't want to
(although being open / welcoming to working with those who do want to
would certainly help); if no one wants the old behavior, the addon can
die when the surrounding code eventually breaks compatibility with the
interfaces it needs, and if people do want the old behavior it can be
maintained outside of the code which has to remain maintainable and has
to be able to adapt to outside changes.

(This is not what I consider to be the _perfect_ solution; the perfect
solution would involve considerably more contributor resources than
Thunderbird or even Mozilla actually has, and a rule to the effect that
"if anyone still wants the old behavior enough to complain about its
being removed, it must not be removed, and must be maintained". I
recognize that that is impractical, though.)

At the very least, _designing_ any given user-visible change with an eye
towards putting in place as few obstacles as possible for users who may
want to revert to the old one would seem like a reasonable idea. Even if
that consideration doesn't end up outweighing the other factors in a
given case, it's valuable to keep it in mind.

(I had rather more to say on the subject of UI changes and
application-development philosophy, but I think it would probably end up
serving as a distraction and do more net harm than good at this point.)

   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20161216/fbe8ff14/attachment-0001.sig>

More information about the tb-planning mailing list