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.
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.
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.
Interestingly, the functional programming crowd sees it the opposite way (according to Curry-Howard isomorphism): every program represents some logical calculus and programs are proofs to some prepositions about our programs that we keep in mind writing the program (and it's possible to get a glimpse of the prepositions using types).
I'd rather want a user agent biased towards me controlling how articles look, attributing the source, but a lot of bad decisions prevented that from being the natural way to use the web.
Back on topic: People often talk about flow charts when transitioning to software, so the notion is not new. It may be rediscovered for some, but that's why we post or talk about things, right? To test our thoughts? Soon somebody will tell me; hey, have you tried user agent XYZ, it does exactly what you describe.
It was a great article indeed, which made me deeply wonder and I will recommend it despite of the colouring.
I'm grateful to the author for discussing all these sad things in a very well reasoned way.
On the "yellow on purple" topic:
The Safari browser has a so called "Reader View".
That formats (most) pages main content into a simple, very readable style.
There is also https://readability.com which is a full-blown web service tackling this problem.
And as I understood there is an open-source library integrated into Google Chrome which deals with decluttering webpages (https://github.com/chromium/dom-distiller)
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.
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.
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.
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.
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.
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.
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.
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.
23 comments
[ 2.2 ms ] story [ 41.2 ms ] threadHowever, a less insightful decision is to have yellow text on a purple background. I can't force myself to read the whole thing.
There's a number of "contrast bookmarklets" that you can use to fix the problem part.
[1] http://megpickard.com/2011/06/nifty-bookmarklet-to-make-web-...
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.
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.
[1]: http://siderea.livejournal.com/1241996.html?format=light
Back on topic: People often talk about flow charts when transitioning to software, so the notion is not new. It may be rediscovered for some, but that's why we post or talk about things, right? To test our thoughts? Soon somebody will tell me; hey, have you tried user agent XYZ, it does exactly what you describe.
I'm grateful to the author for discussing all these sad things in a very well reasoned way.
On the "yellow on purple" topic:
The Safari browser has a so called "Reader View". That formats (most) pages main content into a simple, very readable style.
There is also https://readability.com which is a full-blown web service tackling this problem.
And as I understood there is an open-source library integrated into Google Chrome which deals with decluttering webpages (https://github.com/chromium/dom-distiller)
Phrase not found.
I hate to be the one to tell you ...
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.
Writing code that consists mostly of actual relevant decisions seems like an often-ignored art.
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.
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.