Re: REST impact paper

Patterns were good as a way to pass along otherwise tacit knowledge
(usually) because they had a prescribed structure -- the problem
statement, etc. -- and a somewhat vaguer imperative to be
"generative."  The second part was usually the toughest, because you
wrote patterns based on examples; it was more difficult to test
whether a given pattern was truly generative until people tried to use
the pattern to drive design.  But you ended up with a book that you
could teach from, rules that could be applied to check how people were
doing, etc.

But all of this was built on top of a process:

*  Survey of solutions, applications, whatever in a particular domain
*  Analysis to find common elements (good and bad)
*  Synthesis to write up those common elements into a consistent format
*  Application of the pattern to new situations

IMHO, I think the patterns community made great strides in the middle
stages.  The writers' workshop approach was borrowed as a format for
the analysis and synthesis efforts, so if the workshop participants
had broad experience, they could come up with the necessary examples
that might have been missed by the original author and through
discussion and mutual criticism they often produced pretty good
patterns.

Application of those patterns?  That was a lot harder -- by
generalizing from a set of examples, I think there were implicit
boundaries for where the patterns could be applied successfully (the
local optima), and outside of those often unstated or unknown
boundaries, good patterns became "anti-patterns" -- counter-examples
where a particular approach failed badly.

Still, patterns at their most useful provided a common language for
participants in a design process where there might not have been one
before.

Patterns ended up on a continuum ranging from aphorisms and rules of
thumb (like Postel's Law) on one end, and strict engineering codes
("each work box will contain no more than N wires per cubic inch...")
on the other.

I think the failure/replacement of many promising technologies (SGML
by XML, and then by JSON and YAML) were best described by aphorisms
like "do not repeat yourself," "you aren't going to need it," etc.
Perhaps patterns are over-engineered just as XML was, and simpler
mottos work better than structured rules when you're working in a very
flexible and fluid environment?  I mean, while it can be annoying or
expensive to refactor software, it's a hell of lot less expensive than
correcting mistakes in traditional manufacturing.

There's probably a rule that covers this.  In the world of defense
manufacturing, we had a chart that showed how much of a project's cost
would be committed versus how much of the money was spent, and in
traditional manufacturing, the slope was such that by the time you had
spent 10% of the funds (time, materials), you had actually committed
how you would spend about 90% of those resources.  That's why
waterfall design makes sense when you're building  jets, houses or
dams.  Even if you had to double the time spent on the initial
analysis and design, it was way cheaper than making a mistake that
wouldn't be found until much later in the project.

My guess is that agile techniques try to keep the spend vs. committed
amounts as close together as possible, which is possible given the
extreme flexibility of most software projects.  And aphorisms probably
work almost as well as patterns, which in turn are almost as effective
as more structured approaches (UML?), but much, much cheaper to come
up with and to apply.

Ken Meltsner

On Thu, Sep 7, 2017 at 5:59 PM, Stephen D. Williams <[email protected]> wrote:
>
> On 9/7/17 5:12 PM, Joseph S. Barrera III wrote:
>>>
>>> Each of us only knows a subset, and newbies know nothing.  A good
>>
>> architecture book covers a lot, but
>>>
>>> usually without context of the turning points and their direct and
>>
>> indirect meaning.  It would be helpful to
>>>
>>> have something like a Pirate Code for various branches of technology.
>>
>> You could call them "patterns" or something.
>
>
> That's usually used a bit more narrowly, but close enough.  Or you could
> refer to software patterns, more generically, as concepts.  In my recent way
> of looking at things, they are concepts that can be captured in close to the
> same form, the same morphology.  At least in terms of metadata; the actual
> core concept is still expressed in free form paragraphs and diagrams.
>
> Perhaps most of what I'm thinking about could be covered as design patterns,
> but that isn't what people have done that I've seen so far.  Can you point
> to a better list?
>
> http://www.mcdonaldland.info/2007/11/28/40/
> http://www.dofactory.com/net/design-patterns
> https://en.wikipedia.org/wiki/Software_design_pattern#Classification_and_list
> https://dzone.com/refcardz/design-patterns
>
> That is interesting for what it is, but completely misses things like:
>
> Connection oriented vs. packet switching vs. RPC vs. message routing in
> various senses.
> TCP/IP vs everything else.
> EDI vs. ASN.1 vs. XML vs. JSON vs. MsgPack / many.
> Unix vs. everything else.
> ODBC vs. JDBC vs. various modern solutions.
> OS / VM / containers.
>
> For many of those, you could quantify resources wasted and/or redirected and
> development delay for things that were local minima/maxima in some sense.
>
> sdw
>
>
>>
>> On Thu, Sep 7, 2017 at 4:58 PM, Stephen D. Williams <[email protected]> wrote:
>>
>>> Looks like a cool list.  Have to study it.
>>>
>>> We should consider theory vs. practice, and practice vs. commercial
>>> feasibility / success vs. ubiquity vs. free/wide use separately.
>>> Frequently linked, but they happen in different waves, sometimes widely
>>> separated, so it would be even more muddled to be tracked in one
>>> framework.
>>>
>>> Nothing is very clean.  But some points are clear and others clear enough
>>> to consider.  Besides REST, there are plenty of examples, to wit: IETF,
>>> Jon
>>> Postel etc.  Even an idea as simple as this was a turning point
>>> (regardless
>>> if it was from a single person or a general consensus of the time, as
>>> often
>>> happens):
>>>
>>> "Be conservative in what you send and liberal in what you accept"
>>>
>>> https://tools.ietf.org/html/rfc4677
>>>
>>> In computing, politics, and other areas, there are plenty of singular
>>> concepts that bifurcate groups and/or time periods.  It would be
>>> interesting to catalog those.  A lot of successful companies started with
>>> a
>>> concept that was new or implemented in a new way.
>>>
>>>
>>> More important than the curiosities of history would be usability as a
>>> roadmap of concepts, plateaus of sophistication, and foibles that one
>>> should be aware of.  I use many such principles every day, mostly as
>>> reflex
>>> now.  We could briefly summarize before and after for internalization
>>> justification.
>>>
>>> Each of us only knows a subset, and newbies know nothing.  A good
>>> architecture book covers a lot, but usually without context of the
>>> turning
>>> points and their direct and indirect meaning.  It would be helpful to
>>> have
>>> something like a Pirate Code for various branches of technology.
>>>
>>> http://mentalfloss.com/article/58900/11-rules-actual-pirate-code
>>> http://pirates.wikia.com/wiki/Code_of_the_Pirate_Brethren  Haha
>>> http://pirates.wikia.com/wiki/Pirata_Codex  Jaja
>>>
>>> Coding Codex?
>>>
>>> Stephen
>>>
>>>
>>> On 9/7/17 12:56 PM, Gregory Alan Bolcer wrote:
>>>
>>>> Fill us in.  I don't think computing, science, or software is that
>>>> clean.
>>>>
>>>> I grew up (professionally) with grand computing challenges.
>>>> http://www.grids.ac.uk/Complex/grand_challenges/
>>>>
>>>> I don't think these are the same ones, but it's an interesting list.
>>>> My favorite:  Exploiting division by zero;
>>>>
>>>> Greg
>>>>
>>>> On 9/7/2017 10:21 AM, Stephen D. Williams wrote:
>>>>
>>>>> There are some interesting problems with also capturing the temporality
>>>>> of things, including things that sped up or held back invention /
>>>>> adoption.  I can see a couple possibilities.
>>>>>
>>>> _
>>>>
>>> _______________________________________________
>>> FoRK mailing list
>>> http://xent.com/mailman/listinfo/fork
>>>
>> _______________________________________________
>> FoRK mailing list
>> http://xent.com/mailman/listinfo/fork
>
>
>
> --
> Stephen D. Williams [email protected] [email protected] LinkedIn:
> http://sdw.st/in
> V:650-450-UNIX (8649) V:866.SDW.UNIX V:703.371.9362 F:703.995.0407
> AIM:sdw Skype:StephenDWilliams Yahoo:sdwlignet Resume: http://sdw.st/gres
> Personal: http://sdw.st facebook.com/sdwlig twitter.com/scienteer
>
> _______________________________________________
> FoRK mailing list
> http://xent.com/mailman/listinfo/fork



-- 
After 30+ years of email, I have used up my supply of clever .sig material.
_______________________________________________
FoRK mailing list
http://xent.com/mailman/listinfo/fork