What software is made of

The basic idea, that software is a set of decisions, is insightful. I&#x27;m definitely going to borrow this concept when talking about software design to non-technical people.<p>However, a less insightful decision is to have yellow text on a purple background. I can&#x27;t force myself to read the whole thing.

On larger projects with many contractors and subcontractors, structuring and documenting the (iterative) communication between the &quot;client&quot; and the &quot;contractor&quot; is a challenge. This is largely the problem that the &quot;V&quot; model is designed to solve -- the client &quot;owns&quot; the top of the &quot;V&quot;, 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 &quot;V&quot;. There really isn&#x27;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.

A lot of it is also just boilerplate, if by software we mean code...<p>I&#x27;ve often heard coders talk about &quot;logic&quot; as a vaguely intimidating mass noun, as in &quot;ugh, this module is full of old logic, who knows what&#x27;s going on here?&quot;<p>The word &quot;logic&quot; normally implies structure, coherence, and correctness. In coding, that&#x27;s rarely the case. We still need to learn how to code logically.

Software is an idea morphed into a material configuration.<p>What the idea &quot;hammer&quot; is to wood and metal is the idea &quot;GTA V&quot; to a computer system.<p>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.<p>That&#x27;s why I find these commercials about &quot;stealing software&quot; so funny.<p>&quot;You wouldn&#x27;t steal a car!&quot; as if it was the same as downloading software.<p>It isn&#x27;t.<p>Stealing a car is more like stealing a PC installed with some software.<p>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.

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.<p>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.

Great software is hand crafted from only the finest ASCII

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 &#x2F; business analyst in charge of 5 staff for 6 months.

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.

C-f coffee<p>Phrase not found.