software engineering;  was: Is this official blog article intended as a joke?

Actually, the 'blog makes a useful point:

Most computer science students get to learn high-level programming languages and application development but they don’t really understand computers.

JMO/YMMV:

Now, while interfacing to the real world is fun, RasPi doesn't really address the high-level application problem.  It's still a GNU/Linux box, running a mainframe operating system with dozens of processes.  It's darn cheap for a mainframe, but it's still a mainframe.

If you really want to learn what computers do IMO you really need to learn assembly language and run it on a real mini- or micro-computer with no operating system present to protect you from stomping all over your code and data so that your program goes off to la-la land.  That's when you really see that all that's in computer memory is bit-strings, and the computer will interpret them as instructions or data depending on where you told it to execute -- whether you meant to or not.  Once you've mastered the machine-language level, then you can understand why your C program is misbehaving in that extraordinary fashion.  IMO this mastery is necessary for someone to be called a computer scientist, just as you expect an EE to know how to use Kirchhoff's Laws and a mathematician to be able to do Epsilon-Delta proofs.

> IMO this mastery is necessary for someone to be called a computer scientist,

Of course, computer science is a big field, with many specialties, and many layers

of abstraction, and it's entirely possible for hardware specialists to know very little

about software, and vice versa.  And theoretical computer scientists often know very

little about either software or hardware, focusing their attention on topics like

algorithmic efficiencies that don't provide any benefit on realisitic sized data sets.

Dijkstra famously said "computer science is no more about computers than

astronomy is about telescopes."

Of course, it's still important to know how to read an abend dump when you have to.

Morgaine Dinova wrote:

 

In fact, the finger of blame should mostly point at the "geniuses" of the field because they should be informed enough to understand the root cause of the problem, and able to communicate it to others, including management and beancounters.  They aren't, and they don't.

Bit of a catch22 there though, I tend to find that even when you do understand a problem it's difficult if not impossible to communicate it to non technical people because fundamentally we don't think in the same terms anymore.

selsinork wrote:

 

Bit of a catch22 there though, I tend to find that even when you do understand a problem it's difficult if not impossible to communicate it to non technical people because fundamentally we don't think in the same terms anymore.

Yes, communication can be very difficult.  It becomes even more difficult when engineers see the problem but don't yet have a full solution to offer, because then the communication can be perceived as destruction of an ongoing process without purpose rather than an earnest warning that a cliff lies ahead.

The software crisis lies in that category,  the problem being blatantly obvious to anyone with even half an eye open, yet no full solution being available even in the halls of academia.  Fortunately many partial solutions exist, or at least aids that help avoid the most elementary sources of failure, such as defensive programming practices and test-driven development.

Rather remarkably though, and very unfortunately, advocating even for such simple and relatively painless strategies often falls on deaf ears, for one really terrible reason --- we're human, and deep down it seems that we don't really want to face our own fallibility, even those who recognize the problem.  The "coolness" of programming exacerbates this further, as perhaps a majority of programmers are so busy having fun that they have no inclination to look further than the tips of their fingers.

The problem isn't going to be solved for a long while yet.  There are too many factors reinforcing it, and they're not just technical.

Morgaine.

Hey all, I have moved this discussion to our Raspberry Pi group from Feedback and Support.

Dave,

Hey all, I have moved this discussion to our Raspberry Pi group from Feedback and Support.

The article really is intended for Feedback and Support.  We're just keeping the discussion

going so it stays visible.

selsinork wrote:

 

... Salesmen don't care about the facts and that tends to put salesmen and engineers at odds - the engineer can smell the bullshit the salesman is shoveling regardless of how good the salesman makes it appear.

 

I had the misfortune of having a salesman in the desk over the partition from me for a while, not a pleasant experience and if hadn't been for the partition it would have been much worse

I had a similar experience, though in my case the salesman two cubes away was quite likeable and entertaining.  However, I often heard him talking to prospects trying to sell capabilities I knew were nowhere near being ready for customers.

I could always tell when he was lying, because he prefixed each lie with "to be perfectly honest..."

Morgaine Dinova wrote:

 

... The software crisis lies in that category,  the problem being blatantly obvious to anyone with even half an eye open, yet no full solution being available even in the halls of academia... 

Personally, I don't expect answers to come from academia, at least not from computer science.  I have seen way too much hostility to new ideas in academia (personal experience limited to USA), and anything that requires cooperation is unlikely to get very far in that environment.  Look at the some of the shouting matches we occasionally see here at element14, and we're usually Quiet and Refined .

I see solutions coming from individuals or maybe groups of 2-3, and those solutions will have to succeed in spite of the hostility they will face.

John Beetem wrote:

 

I have seen way too much hostility to new ideas in academia (personal experience limited to USA), and anything that requires cooperation is unlikely to get very far in that environment.

Unfortunately, I have personal experience of that resistance to new ideas in a place where you would expect new ideas to flourish.  I used to advocate strongly on behalf of the emerging Usenet and the early Internet at staff meetings, and as a young lecturer I suffered not only strong denial of their value but outright ridicule by some respected old timers around the table.  It wasn't pleasant.

However, and this is important to keep in mind, the resistance came from a few individuals, and should not be generalized to academia as a whole.  That would be simply incorrect.  As a whole, academia is a strong incubator of new ideas, despite the occasional flawed human.  It gives people time to think (students as well, they're often uninhibited in their thinking and can be very insightful), including the time to think laterally, and very many do exactly that.

Please don't forget that we are all salesmen to a degree :  We have to sell our ideas and if looking for a job we have to sell ourselves.   I know that professional salesman prevaricate ideas but that is their job,  if they know the future or potential of a product.   That's why salesmen should be in on some of the developmental discussions and meetings.

engineers generally find selling ourselves (never mind anything else) a difficult and unpleasant experience, those who don't generally don't stay engineers for long

professional salesmen, generally on comission, have a completely different incentive that's nothing to do with whatever product they're pitching. The engineers get to be the bad guys much later for saying what's been sold is not possible

CHUCK SMITH wrote:

 

That's why salesmen should be in on some of the developmental discussions and meetings.

Salesmen might know something about what past customers have been requesting, so perhaps they might provide some useful input at the earliest "What shall we make?" stage.  They're generally not engineers though, and would tend to disrupt most of the engineering process rather than help once development is under way.  Whatever the Agile nutters may say, you can't keep switching goalposts without engineers losing their sanity.

Salesmen also need exposure to development near the end of a product cycle, for training purposes, so that they're prepared for the next round of sales.  Other than that, best keep Sales away from Engineering, and Marketing even further away.

CHUCK SMITH wrote:

 

That's why salesmen should be in on some of the developmental discussions and meetings.

Salesmen might know something about what past customers have been requesting, so perhaps they might provide some useful input at the earliest "What shall we make?" stage.  They're generally not engineers though, and would tend to disrupt most of the engineering process rather than help once development is under way.  Whatever the Agile nutters may say, you can't keep switching goalposts without engineers losing their sanity.

Salesmen also need exposure to development near the end of a product cycle, for training purposes, so that they're prepared for the next round of sales.  Other than that, best keep Sales away from Engineering, and Marketing even further away.

In your organization, if a salesperson attended a developer's meeting and heard a discussion

where technical buzzwords were used in connection with ideas for possible new features to

add to the product at some indefinite time in the future, which option best describes what the

salesperson would do when talking with potential customers:

                                  not mention it, because he or she didn't understand the buzzwords
                                  mention it, to impress the customer that he or she knew the buzzwords
                                  not mention it, to avoid possibly tipping off competitors about future plans
                                  mention it, hoping customer will ask competitors why they don't also have it
                                  not mention it, because development hasn't even started and priorities will inevitably change
                                  mention it, because the customer is known to have long approval cycles
                                  mention it, to get feedback for developers
                                  mention it, but only if certain that the customer is already interested in that feature

                                  mention it, saying to be honest, the development isn't fully complete
                                  not mention it, to avoid having the customer delay their order waiting for it

                                  not mention it, to maintain confidence of development team
                                   

Submit

I won't click Submit because I don't know what it'll do and I don't feel like examining the HTML or Javascript.  But my response would be none or all of those, because the right answer is:

• Any of the above, depending on their motivation, experience, sense of responsibility, ego, and the phase of the moon.

Morgaine.

I won't click Submit because I don't know what it'll do and I don't feel like examining the Javascript.

What could possibly go wrong?

DId you see the E-14 world map here?

http://www.element14.com/community/community/members/blog/2013/06/14/happy-4th-birthday-element14

It looked to me like Canada was underrepresented, so I wrote a script to change all the

E-14 staff's countries to Canada.  Then I had trouble changing it back.  Still can't get it right for

mriojas

nlarson

dkibbey

That illustrates perfectly why Javascript should be treated like leprosy.

but you don't even need Javascript. 
You can see all the deleteted spam for example, that nobody is

supposed to be able to see except admins, by doing:

wget http://www.element14.com/community/thread/24453

In academia, there's a joke the goes: "The instructor says A, writes B on the blackboard, meant C, the students write down D in their notebooks, and it really was E."

I would suggest that our salesman might only have a foggy idea what was being talked about and might remember a few buzzwords.  When he meets with prospects, they'll ask "can your box do X?"  He'll answer: "Absolutely.  We were just talking about X the other day."  With luck, he'll write down or remember which X the prospects were talking about so when he gets back we'll know how much damage was done.

I jest.  I've worked with many salespeople who knew their products well and realized that you can sell more if your product matches your prospect's actual needs.

Hmmm, I don't think I'm in the market for Bridesmaid Dresses at this time.

Element 14 seems to be doing very effective spam control, as we virtually never see spam in the browser.  The fact that it's available still in the web service but not on the website is perfectly fine.  It even allows researchers to quantify spam volumes if they're into that, or to monitor censorship.  That's a good thing, a part of openness.

That's not the point I was making though.  wget reads URLs as passive data, and that is always safe.  It cannot run embedded code.