
Ask HN: A better mental model to grasp software dev - elisharobinson
I want to know if there are better existing mental models(aka analogies) to understanding software dev?? some feel it is more similar to construction of buildings , some feel it is more similar to cooking , while some feel it should be artistic and some others feel it is more similar to a combat mission ... in any case i want to know your thoughts and mental models to approach software in your day to day life .. thanks in advance
======
hluska
When I was 18, I got a summer job in road construction. My job was to walk up
and down a hot highway for 16 hours a day, picking large rocks out of gravel.

My mental model is "this beats the almighty fuck out of road construction." :)

~~~
elisharobinson
that's a cool story

------
sloaken
Software dev has many aspects that have different analogies.

The first is requirement gathering. This is essential to know what you are
doing, be it from an internal customer or your boss. Best analogy I can think
of is ask a 3 year old to describe in detail the house they live in. Enough
that you can draw a picture of it and provide a fairly accurate floor plan.
Floor plan good enough to use to order furniture against.

Design and coding others have covered.

Testing - ok inspect a car you want to buy ... in extreme detail. Write down
the results.

Documentation - write a diary, detailed that if someone who read it they could
impersonate you.

------
usgroup
The UNIX Philosophy; every day.

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

Make small, quality, interoperable things, and glue them together for as long
as you need them.

~~~
elisharobinson
explains a lot about how Unix became popular

------
Jtsummers
My experience with those analogies is that they fall at different parts of the
programming/software development spectrum.

Writing an algorithm <-> Making a recipe (clear, explicit directions, missing
details means that things don't come out as expected except by chance). Any
analogy based on writing clear directions can be appropriate here.

My preferred analogy here is more like: The computer is the dumbest employee
you will ever have, can you write well enough to communicate to it precisely
what you want? Ever worked with a very literal person? That's the computer.
It'll do precisely what you tell it to do, even if it makes no sense with a
moment's thought.

Larger scale programming (software engineering) has better parallels to the
design, and somewhat to the construction of, buildings. There's a reason we
call them software achitects. The connection is closer to design work rather
than traditional labor (construction). Where there is an analogy with
costruction it's in project management generally, which is a discipline that
spans all design and development fields.

Really, there are many appropriate model to consider and it depends on what
you want to do.

I work in distributed, critical avionics software. I have an agent-based view
of software as a consequence of this. I model (even single threaded programs)
as a collection of agents communicating with each other (a classical view of
OO, also related to the Erlang model, and Hoare's Communicating Sequential
Processes (which I don't apply formally, but I keep the concepts in mind)). I
encourage my new people to play with golang and erlang for a reason (though we
can't apply either for reasons, they're great at informing the mental model I
want them to have). But that's just the software design/writing/modeling
aspect. There's the larger environment in which the software gets developed
that also has to be considered.

Other people have a database oriented views, data flow oriented views, etc.
Sometimes appropriate to their domain and background, sometimes not. You
should learn all of them so that you can communicate.

===============================

Mental models are one of the most useful and most dangerous things. They're
useful, especially when shared, because they allow you to communicate more
effectively with others. They become dangerous when they go unchallenged. My
agent-oriented view? Can you imagine someone writing (for a single 4MHz
microcontroller with maybe hundreds of kilobytes of memory) in that model?
Designing, maybe. But writing the code may require a more explicitly
imperative style just for the constraints placed on the program. On the other
hand, that explicit imperative style doesn't scale well to dealing with
hundreds or thousands of servers (or in my case dozens of nearby radios in a
mesh network). It's appropriate within the radio, but not when conceiving of
the network itself as a computer itself.

~~~
elisharobinson
thanks jt , truer words haven't been said . my interest in mental models for
software dev comes from not being able to relate to software with any physical
phenomenon of giving instructions. I find that most difficult part of software
development is knowing what your doing and knowing if it's useful at all to
what you want to achieve.when these questions are answered I find that
software development is just a matter of solidifying that understanding
although this process of solidifying make take use of different software tools
and proficiency of the tools is also a factor . I find that now days we forget
about trying to understand what we want to accomplish and focus more on tools
. i maybe wrong or to naive but I want to know if at all there is a way to
stare at a problem and walk through a set of steps and come up with a mental
model or a approximate picture of what we want to achieve .

