The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
It is vital, now more than ever. Embedded computing as everywhere, high performance low consumption low cost systems are spreading like butter under the Sun... and being able of tracing faults down to the hw level and fixing one's own tool (aka the workstation) is a skill that never lost value. In fact it is only gaining, due to the usage of industrial PCs in most applications in places of the traditional built-in systems.
Heh, I had a large international company pestering me for almost a year and offering me an amount usually reserved to managers just because I'm one of the few under-40 that has this kind of experience and knowledge. I'll be moving to them in 10 days.
I first read this as meaning the kids are taught the discrete parts of the hardware, and assembling a computer, but after reading other people's comments, I'm not so sure anymore. "Assembler" (if that's what was meant), rather than "assembly", would've removed all doubt.
In any case - assuming my first guess was right:
Yes, I'd like them to know this stuff. But based on what I've seen IRL, I would NOT want most people anywhere near the insides of a computer.
This first bullet item is key to everything!!! However, many software _geniuses_ don't want to admit it.
John Gall, Systemantics
+ A complex system that works is invariably found to have evolved from a simple system that worked
+ A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system
+ In setting up a system, tread softly. You may be disturbing another system that is actually working
+ A system can fail in an infinite number of ways
+ In complex systems, malfunction and even total nonfunction may not be detectable for a long period, if ever
• In general, systems work poorly or not at all.
• New system means new problems.
• Complex systems usually operate in failure mode
Finally I give you the explanation for people arguing about what Agile Methodology is:
A system represents someone's solution to a problem. The system doesn't solve the problem.
But, managers often believe the system (Agile) is the solution. No, it is a possible path to a solution.
Please note that Systemantics does NOT promote "Use agile methods when building large systems". It promotes "Don't build large systems! If at all possible, do not build 'systems' at all!"
So, I think that your first quote is somewhat misleading for the main spirit of the book. The main spirit is "Don't do it". KISS and blackboxing comes much closer to the spirit of Systemantics than agile methods. But even though three out of four software developers cheer enthusiastically (whether wearing a plaid shirt or not...) when hearing a speech promoting KISS, it is all forgotten when they return to their keyboards half an hour later. Knowing a principle doesn't imply that you live by it.
This is actually the first time for the last 25 years that I have seen anyone but myself refer to Systemantics - the book was a cult text when I was a student, but more or less forgotten ten years later. That's a pity. (Maybe it is different across the pond.)
I just happens that today I am wearing a T-shirt with a Systemantics quote: Fail safe systems fail by failing to fail fail safe.
It promotes "Don't build large systems! If at all possible, do not build 'systems' at all!"
It's funny, because one of my own quotes is..."As a dev, writing code may be the last thing you want to do." Devs so often hear a user describe a problem and then start writing code in their heads. I'm more like, "wait a second, I don't think you even need to do that thing. Just stop doing that and your problem is solved." People need to examine the work process they are following before even thinking about solving things with code.
Member 7989122 wrote:
just happens that today I am wearing a T-shirt with a Systemantics quote: Fail safe systems fail by failing to fail fail safe.
People need to examine the work process they are following before even thinking about solving things with code.
Reminds me of a project I worked on, quite a few years ago (1980s), when computers/networks were still something new: We worked through all the work processes of the city administration (a 200.000 people town), from civil enigneering to health services, making a total Entity-Relationship model of the information handled. This was a pure analysis project - only in a few selected sectors could we draw a closed curve around a set of entitie that were to be automated.
You wouldn't believe the praise and acclaim we received for telling them how they were doing their job I think we had people from every department telling us than now I see the dependencies between the cases I handle and the rest of the infrastucutre! Now I see where the bottleneck is in the document flow! Now I see...
Obviously, we did a little more than just describing: The data modelling did identify bottlenecks, unclear responsibilities, dependencies that should be avoided... We did support the guys in the administration find areas for improvement, but essentially, they came up with a lot of improvements themselves, from studying the data model. And they cleaned up a lot, in the non-automated procedures. When computerized tools were introduced several years later, the manual procedures were already cleaned up and streamlined, so that the computerization went very smoothly.
I know that ER modelling is considered outdated today, which I think is a pity, because I have seen it used successfully in both this project and others - much because it is quite well separated from program code, but done at a conceptual level. In the 1990s, several efforts was made to change ER into a way of defining C++ data structures - lots of coding related, not concepts related, facilites were added to ER models, and they lost their simplicity and transparency: You no longer could discuss an ER model with a non-technical customer without intimidating him with technical details. So we kicked out both ER and the customer from the modelling process, which I consider a major loss. Designers/developers today have very few tools suitable for having a dialog with non-techical customer, where the customer directly contributes to the model, and understanding what he is doing.
I know that ER modelling is considered outdated today, which I think is a pity,
I think it is only considered outdated because of things like Agile (which I am a proponent of)saying that you don't need docs (which is an extreme statement, created because so much documentation is done so poorly).
Documents, as in diagrams, and specifically UML and more specifically, the correct and proper UML doc can provide tons of benefit as a communication tool (not as a hammer to hit users over the head with a software designers genius).
You said ER but a very close cousin of that document is the Domain Model which uses the appropriate language (ubiquitous language of the users) and describes things just as you were explaining in the well-done documentation.
Most people just don't even know how to talk about how to build software and systems. They just kind of know how to start coding up some code that runs in an exe in some context. But that ain't creating solutions. And, it may very well be creating more problems.