
What Makes Software Good? - revorad
https://medium.com/@mbostock/what-makes-software-good-943557f8a488#.gb19glwjc
======
akkartik
The D3-specific changes look really cool.

But I'm dissatisfied with the generalizations being proposed. We've heard
before that programs are intended for humans to comprehend and only
secondarily for computers to run. We've heard that programming interfaces are
user interfaces. We've heard many many _many_ attempts at distilling
experience into maxims for others to follow. And yet those vague 'others'
never follow said maxims.

What we tend _not_ to track down is the reason why software is the way it is.
We're warmer when we say the culprit is social rather than technical, but even
that's not quite accurate. The culprit is _political_. Users of a piece of
software aren't all the same. They can be segmented in many many ways, but
I'll focus on one: people upgrading from D3 v3.0 and those coming straight to
D3 v4.0. There's a tension between the needs of these segments that is
identical to class warfare: every change to the API improves the life of the
latter but adds an inconvenience to the former when upgrading. It's quite
possible that D3 has done a good job addressing this tension with semantic
versioning, and by being a tool rather than a service that users can upgrade
on their own schedule. But this tension and the ways we choose to address it
is by far the bottleneck in general. Most tools atrophy and fail to adapt to
changing environments because they get _captured_ [1] by existing users to the
detriment of new users, and eventually to the detriment of everyone.

Repeat after me: compatibility is the mind killer. At least when we are
building software for other programmers rather than end-users, we need a new
social contract that allows newcomers and upgraders to coexist more peacefully
and sustainably.

[1]
[https://en.wikipedia.org/wiki/Regulatory_capture](https://en.wikipedia.org/wiki/Regulatory_capture)

~~~
laughinghan
> What we tend not to track down is the reason why software is the way it is.

The rest of your comment goes in a different direction, but still, you might
be interested in the Big Ball of Mud essay:

> While much attention has been focused on high-level software architectural
> patterns, what is, in effect, the de-facto standard software architecture is
> seldom discussed. This paper examines this most frequently deployed of
> software architectures: the BIG BALL OF MUD. A BIG BALL OF MUD is a
> casually, even haphazardly, structured system. Its organization, if one can
> call it that, is dictated more by expediency than design. Yet, its enduring
> popularity cannot merely be indicative of a general disregard for
> architecture.

[http://www.laputan.org/mud/](http://www.laputan.org/mud/)

~~~
akkartik
Thanks; it was good to reread those patterns. I wonder how the trajectory of
say a life stage like
[http://www.laputan.org/lifecycle/lifecycle.html#Consolidate](http://www.laputan.org/lifecycle/lifecycle.html#Consolidate)
is affected if some or all of the people responsible for previous stages left
in the interim.

------
braderhart
I really wanted to like this article, but it should have been called "What
Makes Software Interoperability Good." There wasn't a lot of useful
information about what makes software good at a high-level.

~~~
codingdave
At a high level, what makes software good has almost nothing to do with how we
code, and almost everything to do with what we code. If it solves a problem,
simply, easily, and quickly, it is good.

~~~
icebraining
What about ethically?

------
drostie
Side note: the images in the middle of the article are Masahiro Mori's 1969
"Fancy Cups", and solve the problem of "you've all put down your drinks and
now nobody remembers whose was whose" with tactile feedback -- without giving
everyone a different style of cup. Right now I and my girlfriend have been
doing the same by collecting a bunch of individual mason jars from different
flea markets, ensuring that none of them look 100% alike, to try to replicate
the same effect on a budget.

As for the article content, I am in general somewhat skeptical of these
highly-cerebral approaches of "what can we learn from that?" \-- it is very
hard to remember those maxims when you are setting out on a new project, even
if they are taped up on your desk! A simpler maxim which would save a lot of
effort is "You only have to solve the immediate problem in front of you --
stop trying to anticipate the next one," and perhaps another is "Don't start
that project until you spend a whole shower/bath thinking up some perspectives
on different ways to solve this problem." As Alan Kay says, the right
perspective is worth 80 points of IQ. Maybe one more is "design top-down:
create a non-working prototype of what you want the end user to be able to do
if they could magically will some functions to exist, then fill in those
functions' type signatures and some stubs, then fill in those functions'
bodies."

So for example I bolted one idea on top of an existing infrastructure this
past December. The preceding infrastructure was really good for what it did --
categorizing books statistically by content -- and this would look at the
categories of the book and then perform some action with it. This works great
for the 90% of the use-cases we care about and we have humans filter the
remaining 10%, making them 10x more efficient -- great! Except for the setup,
which is painfully expensive, because now we have to set up these category
rules etc. for anyone who wants our custom-action service, which turns out to
put 2 layers of indirection between "here is this book" and "here is the
action I want to take on it." Some client says "well I want to filter out the
books containing this phrase", now we have to define some new categories, some
appropriate rules to filter into those categories, and then set up new rules
to act on the assignment of this category -- not fun, and the many-to-many
table joining categories to actions is just annoying to deal with.

Instead I should have implemented (and am now implementing) a little
microlanguage where you can just _read_ what causes the action in one TEXT
field in the database, and decouple these two systems completely. Then it
becomes easy to ask someone, "hey, could you specify those rules? Here's a
widget to test against with validators..." and they can see it for themselves.
Now they can build a bunch of these in some text or Excel or whatever document
they're using, and just send them to me, and all I have to do is change curly-
quotes to straight-quotes.

------
malandrew
The same thing that makes anything good, quality, which I've best heard
defined as "fitness for use"...

------
dschiptsov
Why, fitting to the purpose and attention to details.

The concept of quality from Pirsig, Rand or Japanese traditional crafts.

------
known
requirements != expectations

------
ArkyBeagle
The best software has no need of a user interface at all.

~~~
pandler
In other words, "the best software is no software at all."

~~~
ArkyBeagle
No, software you don't have to interact with - that just does whatever you
need done - seems to me to have more value than something I have to configure.

it still does something, so there's gain, but the cost is lower than if you
had to configure it.

