Ask HN: A better mental model to grasp software dev
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
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." :)
that's a cool story
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.
The UNIX Philosophy; every day.
https://en.wikipedia.org/wiki/Unix_philosophy
Make small, quality, interoperable things, and glue them together for as long as you need them.
explains a lot about how Unix became popular
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.
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 .