|
They should change it to
- intro programming (2)
- data structures
- googling for the solution
- discrete math
- upper level electives
|
|
|
|
|
googling for the solution Ask Siri/Cortana
FTFY
If you can keep your head while those about you are losing theirs, perhaps you don't understand the situation.
|
|
|
|
|
So....you think it's a good idea to write code without understanding what a CPU or memory are...
On second thought, there is a degree that basically does what you're talking about: CIS. That's the people that learn to write horribly hacky things in VBA.
"Never attribute to malice that which can be explained by stupidity."
- Hanlon's Razor
|
|
|
|
|
swampwiz wrote: computer organization / assembly
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
John Gall: • 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:
John Gall 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.
Read more at: John Gall - Wikiquote[^]
Now that I've stirred the pot...have a nice evening. 
|
|
|
|
|
they all boil down to : sh*t happens if you let it happen.
I'd rather be phishing!
|
|
|
|
|
Maximilien wrote: they all boil down to : sh*t happens if you let it happen.
Nice! That's a very good summary.
I could just put that on a bumpersticker and call it my Software Development Architecture Warning. 
|
|
|
|
|
I'd say: S#!t happens. Period.
If you try to prevent s#!t from happening by holding it back, you'll eventually end up with a terrible mess.
It's better to let s#!t happen in a controlled manner.
BREAKING FAKE NEWS: Trump told the truth!
|
|
|
|
|
For a moment I thought that you were referring to John Galt... 
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
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".
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
