
What software is made of - danohuiginn
http://siderea.livejournal.com/1241996.html#cutid1
======
probablyfiction
The basic idea, that software is a set of decisions, is insightful. I'm
definitely going to borrow this concept when talking about software design to
non-technical people.

However, a less insightful decision is to have yellow text on a purple
background. I can't force myself to read the whole thing.

~~~
GlennS
I did read the whole thing - it was a really well written and enjoyable
article. I did have to slog through though, because of the yellow on purple.

My favourite bits:

Waterfall as a expression of power and hierarchy within an organisation,
something like: "I tell you, lowly worker, what to do" (my words).

This characterisation of a good client: "These are people who will be a
pleasure to work with: they are forward thinking, attentive to detail, serious
about this project, and have some idea of what it is they want their program
to do."

The idea of a cultural conflict between people who value good design and want
to spend time on it, and other who hold it in in contempt. Not something I'd
thought about before, beyond some idea that the market doesn't demand quality,
and so worth a chew over.

~~~
sageikosa
Actually the "waterfall" effigy defined in various manifestos was the revolt
against civil engineering project managers who entered the software
engineering field and believed that "building software" was like building a
bridge, a skyscraper, or a sewer system.

The correct solution space wasn't to abandon dependencies and long range
planning, but to recognize that software engineering is a specific type of
process engineering that involves partially or completely automated processes.

Software doesn't describe the state of a machine in so much as it describes a
process. Often developers don't recognize this so much because many of the
terms have been concretized into the operating system (ie, process) and get
thought of as a container for software instead of the representation of an
automated process working in concert on shared resources.

And consequently software is complete when the process is well-defined and
repeatable, not when things are bolted together.

------
w_t_payne
On larger projects with many contractors and subcontractors, structuring and
documenting the (iterative) communication between the "client" and the
"contractor" is a challenge. This is largely the problem that the "V" model is
designed to solve -- the client "owns" the top of the "V", and puts effort
into understanding the problem that they want to solve (Systems Engineering
and Modelling) -- the contractor integrates with that model to (iteratively)
improve their understanding of the component that they are providing,
particularly in terms of the yield curve for the KPIs that their component
must deliver -- with that relationship recursing down (sub)contractual
relationships until you get to the bottom of the "V". There really isn't that
much difference in the fundamentals between software engineering and other
disciplines, although the details of the interfaces and the impact of
automation is, of course, more significant.

------
mbrock
A lot of it is also just boilerplate, if by software we mean code...

I've often heard coders talk about "logic" as a vaguely intimidating mass
noun, as in "ugh, this module is full of old logic, who knows what's going on
here?"

The word "logic" normally implies structure, coherence, and correctness. In
coding, that's rarely the case. We still need to learn how to code logically.

~~~
lubonay
According to the article's terms I think boilerplate can be referred to as
"trivial decisions", e.g. "there's no elevator in this building so I gotta
trudge up the stairs" \- there's no real decision there besides "do" or
"don't" and a bunch of boring work you have to do in order to reach your goal.

~~~
mbrock
I'm thinking also of stuff like complex hierarchies of "object orientation"
that don't embody any actual logic, but only serve to impose a "structure"
that may or may not have benefits.

Writing code that consists mostly of actual relevant decisions seems like an
often-ignored art.

------
k__
Software is an idea morphed into a material configuration.

What the idea "hammer" is to wood and metal is the idea "GTA V" to a computer
system.

The only difference is, that everyone can tell his computer to configure
itself for running GTA with information from its installation package. But one
can not simply tell its wood and metal to configure itself to be a hammer with
a documentation of how to build a hammer. The documentation is more of a
source code and needs a compiler, a craftsman or machine, that could make the
hammer with this docs.

That's why I find these commercials about "stealing software" so funny.

"You wouldn't steal a car!" as if it was the same as downloading software.

It isn't.

Stealing a car is more like stealing a PC installed with some software.

Downloading software is more like stealing the documentation of how to build a
car in some format that only the materials cars are build of can understand.

------
goblin89
Empathy looks like the key to making better design decisions, since defining
behavior is basically communicating. (This is why incidental design leaves bad
taste—it’s noise.) Singling out software as being made of decisions is not
entirely fair though, as this applies well generally to significant part of
our conscious reality.

On a higher level there are decisions that do not directly define the behavior
of the end thing under some specific conditions, but rather apply to the
process by which that design happens. Those meta-decisions can also be
incidental, and can be felt if you take the end thing as existing in longer
time frame.

------
mikerg87
Great software is hand crafted from only the finest ASCII

~~~
omginternets
Ah yes, I hear Kuwaiti ASCII is the best, despite the international embargo.

------
sjclemmy
Reminds me of a project I signed up for, where I said I could commit a couple
of days a week to ensure they were on the right lines. I ended up as the full
time product owner / business analyst in charge of 5 staff for 6 months.

------
phkahler
And yet there is mention of machine code and turing machines in there. TFA is
not going to explain what software is to a lay person. It does offer some help
for those trying to craft such an explanation though.

------
TurboHaskal
C-f coffee

Phrase not found.

~~~
pestaa
Good point. However, I write good software, but barely drink coffee. Where
does that leave us?

~~~
omginternets
>I write good software, but barely drink coffee.

I hate to be the one to tell you ...

