Re: [digital-curation] Simple or complicated? [somewhat OT] [tl;dr]
Ed Summers
really nice exposition on why "simplicity is in the eye of the
beholder". Often the key to simplicity is working with people who see
things in roughly the same way :-)
As for Brian's point about simplicity for programmers having an
inversely proportional relationship to simplicity for end users: I
think the only thing to keep in mind that the distinction between
programmers and end users isn't always clear.
/me steps onto soapbox
As a software developer I'm constantly using, or inheriting someone
else's code: be it a third party library that I have a dependency on,
or a piece of software that somebody wrote once upon a time, who has
moved on elsewhere. In both these cases I'm effectively an end-user of
a program that somebody else designed and implemented. The interfaces
and abstractions that this software developer has chosen are the
things I (as an end user) need to be able to understand and work with.
Ultimately, I think that it's easier to keep software usable for end
users (of whatever flavor) by keeping the software design itself
simple. Simplicity makes the software easier to refactor over time
when the inevitable happens, and someone wants some new or altered
behavior. Simplicity also should make it clear when a suggested change
to a piece of software doesn't fit the design of the software in
question, and is best done elsewhere. One of the best rules of thumb
I've encountered over the years to help get to this place is the Unix
Philosophy:
Write programs that do one thing and do it well. Write programs to
work together. [1]
As has been noted elsewhere [2], composability is one of the guiding
principles of the Microservices approach--and it's why I'm a big fan
(in principle). Another aspect to the Unix philosophy that
Microservices seems to embody is:
Data dominates. [1]
The software can (and will) come and go, but we are left with the
data. That's the reality of digital preservation. It could be argued
that the programs themselves are data, which gets us into sci-fi
virtualization scenarios. Maybe someday, but I personally don't think
we're there yet.
Another tool I've found that works well to help ensure code simplicity
has been unit testing. I guess it's a bit of a religion, but at the
end of the day, writing tests for your code forces you to use the
APIs, interfaces and abstractions that you are creating. So you notice
sooner when things don't make sense. And of course, they let you
refactor with a safety net, when the inevitable changes rear their
head.
And, another slightly more humorous way to help ensure simplicity:
Always code as if the person who ends up maintaining your
code is a violent psychopath who knows where you live. [3]
Which leads me to a jedi mind trick my former coworker Andy Boyko
tried to teach me (I think): it's useful to know when you don't have
to write any code at all. Sometimes existing code can be used in a new
context. And sometimes the perceived problem can be recast, or
examined from a new perspective that makes the problem go away.
I'm not sure what all this has to do with digital preservation. The
great thing about what you are engaged in at CDL w/ microservices is
that you are trying to focus on the *what*, and not the *how* of
digital preservation. Whatever ends up happening with the
implementation of Merritt itself, I think you guys are discovering
what the useful patterns of digital preservation are, trying them out,
and documenting them...and it's incredibly important work that I don't
really see happening much elsewhere.
//Ed
[1] http://en.wikipedia.org/wiki/Unix_philosophy
[2] http://or2010.fecyt.es/Resources/documentos/GSabstracts/curationMicro-services.pdf
[3] http://c2.com/cgi/wiki?CodeForTheMaintainer
BRIAN TINGLE
As for Brian's point about simplicity for programmers having an
inversely proportional relationship to simplicity for end users: I
think the only thing to keep in mind that the distinction between
programmers and end users isn't always clear.
Ed Summers
<brian.tingl...@gmail.com> wrote:
> That was sort of my point, but let me elaborate a little. Complexity is.
> It can not be destroyed, it can only be hidden. Take a few simple things
> and link them together and complexity emerges very quickly. As "programmers"
> we need to take the hit and swallow the complexity so at the end of the day
> it looks simple to the "end user" (whether a clean API or a clean UX).
I like the sound of that. Emergent complexity from simple pieces is a
great goal to have.
//Ed
Martin Haye
Perhaps emergent simplicity from a set of conceptually simple pieces (that
may be complex inside) is a better goal.
--Martin
> --
> You received this message because you are subscribed to the Google Groups
> "Digital Curation" group.
> To post to this group, send email to digital-...@googlegroups.com.
> To unsubscribe from this group, send email to
> digital-curati...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/digital-curation?hl=en.
>
Erik Hetzner
Ed Summers wrote:
>
> Erik, thanks for the link to Odersky's piece on simplicity. It's a
> really nice exposition on why "simplicity is in the eye of the
> beholder". Often the key to simplicity is working with people who see
> things in roughly the same way :-)
>
> As for Brian's point about simplicity for programmers having an
> inversely proportional relationship to simplicity for end users: I
> think the only thing to keep in mind that the distinction between
> programmers and end users isn't always clear.
See also the discussion on the interrupted system call in Worse is
better. Should we make the implementation hard and make the interface
easy, or make the implementation easy and the interface hard?
> […]
>
> One of the best rules of thumb I've encountered over the years to
> help get to this place is the Unix Philosophy:
>
> Write programs that do one thing and do it well. Write programs to
> work together. [1]
>
> As has been noted elsewhere [2], composability is one of the guiding
> principles of the Microservices approach--and it's why I'm a big fan
> (in principle). Another aspect to the Unix philosophy that
> Microservices seems to embody is:
>
> Data dominates. [1]
>
> The software can (and will) come and go, but we are left with the
> data. That's the reality of digital preservation. It could be argued
> that the programs themselves are data, which gets us into sci-fi
> virtualization scenarios. Maybe someday, but I personally don't think
> we're there yet.
The Unix philosophy is interesting. Someday I would like to try to use
an OS build on it. Unix might be a nice start, if I get rid of sed &
awk (what is the one thing those two do?), perl, python, & ruby (shell
should be enough), , emacs (an OS within an OS), the GNU utils
(bloated!), vi (where are the text streams?), X, firefox, ... I guess
I could keep mh for reading mail. curl & w3m make a browser, (although
really curl, ftp AND http? what happened to doing ONE thing?).
:) In fact I think that Richard Gabriel’s “Worse is better” has a lot
to teach us. Especially as he argues with himself. [1] And probably
also Plan 9, since it seems to take Unix & run with it.
The real questions, I think, what is the level of composition [2], and
what is the size of the one thing that we do well?
As you say, data is definitely the start of the answer to these
questions.
best, Erik
1. http://dreamsongs.com/WorseIsBetter.html
2. e.g., function (lisp) or program (unix)
Brian Tingle
>
> Perhaps emergent simplicity from a set of conceptually simple pieces (that
> may be complex inside) is a better goal.
>
Also related: Simplicity vs. Choice by Joel Spolsky
Brian Tingle
The Law of Conservation of Tradeoffs / Ayende @ Rahien: Unnatural acts
on source code
posted on Friday, September 03, 2010 12:00 PM
http://ayende.com/Blog/archive/2010/09/03/the-law-of-conservation-of-tradeoffs.aspx
and this comment
http://ayende.com/Blog/archive/2010/09/03/the-law-of-conservation-of-tradeoffs.aspx#41885
also this
http://ayende.com/Blog/archive/2010/09/03/the-law-of-conservation-of-tradeoffs.aspx#41886