
The next major leap in software development needs mental model visualisation - hoodoof
I worked for a startup back in about 1990 and the visionary guy who ran that startup said something that made me think for many years afterwards.  He said &quot;there will be a revolution in software&quot;.<p>At the time I didn&#x27;t know what he meant.  Probably he didn&#x27;t either.  But soon the web came and along with it several revolutions in software development including new languages, better languages, better processes, better information for programmers via the web and collaboration for programmers on problems via StackOverflow.<p>But it is still incredibly hard to learn new software technologies.<p>The main reason is because it is so hard to form a mental model of the technology that you are working with.<p>Consider reactjs.  You&#x27;ll only really start to work with it effectively when you understand the mental model of it - that there are components, and components have a lifecycle, and data flows through them in one direction.  When you&#x27;ve studied it and programmed it for a certain amount of time then a mental model forms in your head and that&#x27;s when you really can get going driving that technology effectively. And that&#x27;s true not just for ReactJS but any development technology.<p>And until that mental model fully forms, you&#x27;re digging around in the dark, puzzled, wasting time, trying to understand why things don&#x27;t work in the way you expect, doing it wrong and being very frustrated.<p>So the question is, &quot;is there a better way to convey the mental model of a software system?&quot;.<p>I feel like some sort of visualisation system is needed that can effectively convey the mental model of a given piece of software.<p>When we get such a thing, and when it works really well, software developers will be able to much more rapidly come up to speed by examining the visualisation and seeing how the parts hold together, instead of the current way of forming a mental model which is reading lots of documentation and going through a long and painful learning process.
======
stray
Like a DFD?

Data flow diagrams were proposed by Larry Constantine, the original developer
of structured design, based on Martin and Estrin's "Data Flow Graph" model of
computation. Starting in the 1970s, data flow diagrams (DFD) became a popular
way to visualize the major steps and data involved in software system
processes. DFDs were usually used to show data flows in a computer system,
although they could in theory be applied to business process modeling. DFD
were useful to document the major data flows or to explore a new high-level
design in terms of data flow. (copy/pasted from wikipedia)

~~~
hoodoof
I guess a DFD is one form of visualisation.

For me, the outcome of learning a software technology is almost like a 3d
image in space of the software and how it works. It's not as clear as a real
3d image of course but in a vague way that is what it is.

Imagine if you asked 1,000 programmers to "draw a picture of the mental model
of X software system", you would find a small handful of really good
visual/spatial conceptualisations of what that software is and how it works.
The question is, can that process of drawing a good mental model visualisation
be brought into the real world as some sort of definable process?

I would find it dramatically easier to learn new technologies if the start
point was a really good 3d visualisation.

It's hard to explain exactly what I have in mind because it's not a solved
problem.

~~~
stray
I like the way you think.

The problem here is probably that if you asked 1000 programmers to draw
something -- they'd all be limited to the two dimensions they can commit to
paper (or whiteboard).

Even a photograph is a projection of a 3d scene down to 2d.

 _My_ mental model of react is a cascading DFD.

But if that doesn't work for you -- imo you should definitely come up with
your own notation. After all, all models are wrong in some way but many are
useful.

~~~
hoodoof
Turns out the web is really good at getting 1,000 people to do something.

Maybe some enterprising entrepreneur will find a way to make this new
revolution happen by harnessing the power of everyone to create great mental
models for software.

------
teslabox
I read about this 'visualization' ability that people are said to have during
my senior year of high school. It's sort of like dreaming, in that you can
'see' pictures in a 'mind's eye'. I remembered having two dreams from growing
up, so I kind of knew what this 'visualization' was supposed to be like. It's
supposed to be a natural human ability, but for me it was not easy (some
people are auditory, others kinesthetic, etc etc, but all the usual techniques
didn't seem to help.)

Figuring out how to relax my body was 8/10ths of the journey.

------
palidanx
To me, the closest to a mental model would be a combination of

\+ domain model diagrams (illustrates domain objects and cardinality
relationships)

\+ sequence diagrams (expressing flow in between systems)

\+ state diagrams

But what I found in the real world is not many people use these UML diagrams
except in really large companies.

I totally agree that the current ways of forming mental models (through
watching tutorials, reading docs, writing code, and taking notes) is super
painful.

------
codeonfire
>is there a better way to convey the mental model of a software system?

There is UML but that's mainly to explain stuff to non-engineers and turned
out to be a total waste of time in 90% of cases. Documentation becomes rapidly
outdated and costs money to maintain. Do you want someone updating stupid
arrows and boxes in a visio file for $200 an hour? Engineers develop an
intuition of why things don't work the way you expect just as a mechanic
develops an intuition about why your car doesn't run the way you expect.

