Sometimes programmers make a complicated design in anticipation of
possible future changes that never happen (instead it's either no
changes, other changes, or just replaced entirely without any reuse).
It's hard to predict in advance *which* changes will be useful to make.
And designs aren't just "better at any and all changes" vs. "worse at
any and all changes". Different designs make different categories of
changes harder or easier.
So how do you know which structure is good? Rules of thumb from past
work, by many people, doing similar kinds of things? Is the software
problem – which is well known – just some bad rules of thumb (that
have already been identified as bad by the better programmers)?
> “It” can be software, an object like a hammer, ideas, or processes
> (like the processes factory workers use). Different software designs
> are easier to add features to than others. You can imagine some hammer
> designs being easier to convert into a shovel than others.
giant hammers? lol. most hammers are too small to make much of a shovel.
this is related to the desire for FI emails to be self-contained (have
some independence/autonomy). this isn't threatened by links/cites cuz
those are a loose coupling, a loose way to connect to something else.
> - Easier to reuse for another purpose. (This is related to
> changeability and to components. Some components can be reused without
> reusing others.)
but, as above, there are different ways to reuse something and you don't
just optimize all of them at once. you need some way to judge what types
of reuse are valuable, which partly seems to depend on having partial
foresight about the future.
> - Internal reuse (references, pointers, links) rather than new copies.
> (This is usually but not always better. In general, it means the
> knowledge is present that two instances are actually the same thing
> instead of separate. It means there’s knowledge of internal
> groupings.)
>
>
> Good structures are set up to do work (in a certain somewhat generic
> way), and can be told what type of work, what details. Bad structures
> fail to differentiate what is parochial details and what is general
> purpose.
>
>
> The more you treat something as a black box (never take it apart,
> never worry about the details of how it works, never repair it, just
> use it for its intended purpose), the less structure matters.
sometimes the customer treats some as a black box, but the design still
matters a lot for:
- warranty repairs (made by the company, not by the customer)
- creating the next generation production
- fixing problems during development of the thing
- the ability to pivot into other product lines (additionally, or
instead of the current one) and reuse some stuff (be it manufacturing
processes, components from this product, whatever)
- if it's made out of components which can be produced independently and
are useful in many products, then you have the option to buy these
"commodity parts" instead of making your own, or you can sell your
surplus parts (e.g. if your factory manager finds a way to be more
efficient at making a particular part, then you can either just not
produce your new max capacity, or you could sell them if they are useful
components to others. or you could use the extra parts in a new product.
the point was you can end up with extra capacity to make a part even if
you didn't initially design your factory that way.)
> In general, the line between function and design is approximate.
like the line between object-discussion and meta-discussion is
approximate.
as discussion structure is crucial (whether you talk about it or not),
most stuff has more meta-knowledge than object-knowledge. here's an
example:
you want to run a small script on your web server. do you just write it
and upload? or do you hook it into existing reusable infrastructure to
get automatic error emails, process monitoring that'll restart the
script if it's not running, automatic deploys of updates, etc?
you hook it into the infrastructure. and that infrastructure has more
knowledge in it that the script.
when proceeding wisely, it's rare to create a ton of topic-specific
knowledge without the project also using general purpose infrastructure
stuff.
A lot of the difference between a smartphone and a computer is the
shape/size/weight. That makes them fit different use cases. An iPhone
and iPad are even more similar, besides size, and it affects what
they're used for significantly. And you couldn't just put them in an
arbitrary form factor and get the same practical functionality from
them.
Discussion and meta-discussion are related too. No one ever entirely
skips/omits meta discussion issues. People consider things like: what
statements would the other guy consent to hear and what would be
unwanted? People have an understanding of that and then don't send porn
pics in the middle of a discussion about astronomy. You might complain
"but that would be off-topic". But understanding what the topic is, and
what would be on-topic or off-topic is knowledge *about* the discussion,
rather than directly being *part of* the topical discussion. "porn is
off topic" is not a statement about astronomy – it is itself meta
discussion which is arguably off topic. you need some knowledge about
the discussion in order to deal with the discussion reasonably well.
> Sometimes it’s useful to mentally separate them but sometimes it’s
> not helpful. When you refactor computer code, that’s about as close
> to purely changing the form as it gets. The point of refactoring is to
> reorganize things while making sure it still does the same thing as
> before. But refactoring sometimes makes code run faster, and sometimes
> that’s a big deal to functionality – e.g. it could increase the
> frame rate of a game from non-playable to playable.
>
> Some designs *actively resist change*. E.g. imagine something with an
> internal robot that goes around repairing any damage (and its
> programmed to see any deviation or difference as damage – it tries
> to reverse *all* change). The human body is kind of like this. It has
> white blood cells and many other internal repair/defense mechanisms
> that (imperfectly) prevent various kinds of changes and repair various
> damage. And a metal hammer resists being changed into a screwdriver;
> you’d need some powerful tools to reshape it.
memes resist change too. rational and static memes *both* resist change,
but in different ways. one resists change without reasons/arguments, the
other resists almost all change.