|
That's really funny, because I stumbled upon the quote by John Gall in a book I was reading and I thought the exact same thing. I was like, "Is this that Ayn Rand guy?" 
|
|
|
|
|
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.
|
|
|
|
|
Member 7989122 wrote: 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.
Uh...are you John Gall?
|
|
|
|
|
raddevus wrote: 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.
|
|
|
|
|
Great story. 
Member 7989122 wrote: 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. 
Again, great story. Thanks for sharing.
|
|
|
|
|
Were you strolling by The New Old Thing recently? 
GCS d-- s-/++ a- C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
den2k88 wrote: Were you strolling by The New Old Thing recently?
I love repeating old, old ideas to new people (devs) so they open their eyes and see that the "new" methodologies have all been done before, they just have a shiny new name. 
|
|
|
|
|
The next time one of our service folks, who damned well ought to know better, includes a screen 'capture' taken from 3 feet away with their phone in a bug report, I'm going to lose my sh*t  .
Software Zen: delete this;
|
|
|
|
|
Gary Wheeler wrote: includes a screen 'capture' taken from 3 feet away with their phone
Yeah, you're right - that's far too close.
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Our application controls a printing press. The operator typically stands 2+ feet back from the monitor.
Software Zen: delete this;
|
|
|
|
|
Shouldn't you be seeing the back of the operator's head then in those pictures taken 3 feet away?
|
|
|
|
|
That would make it the right kind of screen shot. After all, isn't it sometimes the bit between the ears that's the root cause?
|
|
|
|
|
I was going for a variation on PEBKAC. As described, the picture would include the source of the problem.
|
|
|
|
|
That is too funny! Did they capture the back of the users head for you too?
|
|
|
|
|
Gary Wheeler wrote: The next time...
Gary Wheeler wrote: ...I'm going to lose my sh*t
Next time?
I think you already did. It just didn't have an outward effect.
|
|
|
|
|
Still better that: "it doesn't work".
|
|
|
|
|
Guilty as charged, but I think it was legit in my case; just as everyone else does.
My situation:
1. Stupid hybrid hard-drive on laptop did not get along with Win 10 PreFetch, causing machine to overheat and shutdown.
2. Event log only had generic unexpected shutdown messages.
3. BIOS event log actually was logging all the shutdowns.
Been having the problem for about 6 months intermittently with no actions taken because they could not see evidence of what actual error was. Pulled up the BIOS event log and snapped a pic. Next day new laptop with an SSD the same size as what i had
Director of Transmogrification Services
Shinobi of Query Language
Master of Yoda Conditional
|
|
|
|
|
Those I can understand. The controller app, which is a normal Windows app, not so much. [PrtScn] and Alt-[PrtScn] are your friends.
Software Zen: delete this;
|
|
|
|
|
Does it still annoy if they have an optical zoom?
|
|
|
|
|
Oh you just had to go there, didn't you?
Optical zoom is ok. Digital zoom causes immediate fecal loss.
Software Zen: delete this;
|
|
|
|
|
Gary Wheeler wrote: Digital zoom causes immediate fecal loss.
You crapped your pants?
"Never attribute to malice that which can be explained by stupidity."
- Hanlon's Razor
|
|
|
|
|
See the OP; I lost my sh*t.
Software Zen: delete this;
|
|
|
|
|
|
A very long time ago a customer of mine had a printer that printed the error reports...
|
|
|
|
|
At one time we included one of our small ink-jet printers[^] as a log printer on these systems.
Software Zen: delete this;
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
