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.

coder27 wrote:

 

The solution to complexity is abstraction.  A single person can run a large company

or run a large nation, but not by doing all the jobs that a sole proprietor does.  Instead,

they operate at much higher levels of abstraction.

Not sure I really agree with that.  I accept that abstraction is necessary, but I'd argue that it's a necessary evil.

The problem with abstraction is that by definition it leads to the problem Morgaine brought up that no one person has a clue how it all works, or even how it's supposed to work. It also leads to the problem that once it becomes obvious that somethings broken it's often impossible to fix in any meaningful way.

You mention large companies or nations. I think they're often a perfect example - you look at the individual, abstracted, parts and they all look perfectly reasonable, but put them together and the result is incoherent and often fails even the most basic common sense analysis.

I accept that abstraction is necessary, but I'd argue that it's a necessary evil.

Yes, no doubt that large companies, nations, etc. are run with huge inefficiencies.

Sometimes that is intentional.

Similarly, there are a lot of examples where inefficiency is inherent. 

For example, airliner load factors.  It's tempting to see an airliner flying

with empty seats, and say that's inefficient because the seats are

going to waste and any revenue that could be obtained by filling them

would go directly to the bottom line profit. 

But an airline intentionally flys more seats on any particular route than

it expects to fill, in order to accommodate last-minute bookings from

high-paying business travelers.  It's just as important to avoid the waste

of turning away last-minute bookings because your plane is full than it is

to avoid the waste of flying empty seats.

The idea of abstraction is that low-level details are often not of critical

importance at higher levels of design.  For example in coding, an

assembly language programmer might care a lot about which register

holds which variable, in order to maybe keep two variables in adjacent

registers so they can be moved at the same time in a single double-word

move instruction.  But that's of no concern to the project's chief architect.

Every low-level detail needs to be worried about by someone, but

no single person needs to worry about every low-level detail.

Great post, Nelson.  I really like the Orson Scott Card essay -- hilarious and insightful.

Dudley Nelson wrote:

 

Ultimately, it's quite possible to write bad code in any language. The more powerful the language, the easier it is to paint yourself into a corner, and find yourself with a sticky problem that you have to fudge your way out of...

Reminds me of some classic C versus C++ jokes (from memory):

1.  C gives you enough rope to hang yourself.  C++ gives you enough rope to tie up everybody in your neighborhood, rig a small ship, and still have enough left over to hang yourself from the yard-arm.

2.  With C, it's easy to shoot yourself in the foot.  With C++ it's harder, but when you do you blow your whole leg off.

Dudley Nelson also wrote:

 

Now, that all said, it's fair to say that all software ships with bugs; it is part of the nature of software, and it happens for all the reasons everyone said.

All software that performs a non-trivial function has bugs.  There are just way too many moving parts, and when you try to fix the code the bugs scurry away to other parts of the program, just like in the song:

99 little bugs in the code,
99 bugs in the code...
Take one out, compile again,
100 little bugs in the code.
[Repeat until bug count goes to zero.]

As long as we're sharing humorous bits about software engineering, here's one of my favorites: Software Engineering: Now with Cats.

Dudley Nelson wrote

 

However, what got me out of lurking on this post and actually posting on this discussion was the last post by Selsinork, which reminded me of an excellent article once written by Orson Scott Card. This is a jaded example, but it definitely points at some of the key problems in software development - how it is handled by non-software types, and especially by management. The world has changed in many ways since this article was written, but in many ways, it remains the same. A large number of problems are caused by external people not understanding either how software works, or how the people who work on software work.

A great example of no matter how much things change they really just stay the same. I don't think that has lost any relevance in all these years.

coder27 wrote:

 

Every low-level detail needs to be worried about by someone, but

no single person needs to worry about every low-level detail.

I couldn't agree more.. Unfortunately it's also exactly the problem.  Someone five levels up the abstraction tree makes an innocuous decision because he doesn't think he needs to care about the person trying to keep those two values in the same register, but by the time the decision makes it all the way down, that assembly language programmer can no longer do what's required without forcing a re-write at every other level. Resulting bodged solution unsurprisingly has issues because a very frequently executed action goes from a single cycle to something that takes very many orders of magnitude longer.

I know of at least one example where this sort of thing forced changes in hardware to compensate for software design that was unchangeable due to this way of thinking.

John Beetem wrote:

 

As long as we're sharing humorous bits about software engineering, here's one of my favorites: Software Engineering: Now with Cats.

I like it

Someone five levels up the abstraction tree makes an innocuous decision because he doesn't think he needs to care ...

Yes, sometimes abstractions leak, but hopefully it's the exception rather than the rule.

As you probably know, there is a software engineering notion of "information hiding"

that is often misunderstood.  The goal is to separate interface from implementation,

with the implementation details hidden from users of the abstraction so that they can't

unwittingly rely on them, which would endanger the system if the details are changed.

Some people think information hiding is bad in that it prevents them from maximizing

efficiency by taking advantage of implementation details that they don't expect will

actually change, such as multiplying an integer by 2 by shifting it left one bit, on the

assumption that it's represented in base 2 and always will be.

Dudley Nelson wrote:

 

excellent article once written by Orson Scott Card. This is a jaded example, but it definitely points at some of the key problems in software development - how it is handled by non-software types, and especially by management. The world has changed in many ways since this article was written, but in many ways, it remains the same. A large number of problems are caused by external people not understanding either how software works, or how the people who work on software work.

Although poor management is common in all fields, the core problem in software isn't lack of understanding of software by non-software-types, but lack of understanding of software by everybody involved in the process, Alpha Programmers included.  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.

After all, management deals with huge projects in many other fields of engineering and still succeeds in delivering bridges that don't fall down continually, complex modern cars that are much more reliable than their drivers, and space rovers that continue to explore Mars some 10 years after the end of a nominal 90-sol mission.  It is not beyond the capabilities of engineers and management to make extremely complex systems that work to spec.

Unfortunately, the vast bulk of software development is not an engineering discipline at all, but a rather ad hoc craft with very little in the way of engineering methodology, and frequently no measurement or analysis done at all.  Although Computer Science is a formal discipline, it underpins the creation of software only in principle, rarely in practice to any great extent.  Well-chosen scalable algorithms or the use of formal language grammars is often as close as CompSci gets to helping a software project achieve its goals.  The situation is very bad indeed.  The Software Crisis that was so often described in the 80's is still present and shows no signs of abating.  It's an extreme embarassment to those of us who would like to consider themselves engineers through long experience in the discipline, but in all honesty cannot.

Orson Scott Card's little article is certainly funny.  Unfortunately it also perpetuates the myth that  Alpha Programmers are on top of things, and that if only they were left alone, coders and their coffee and pizzas will solve everything.  If only it were so.

Morgaine.

Morgaine Dinova wrote:

 

Although poor management is common in all fields, the core problem in software isn't lack of understanding of software by non-software-types, but lack of understanding of software by everybody involved in the process, Alpha Programmers included.  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.

My opinion:  I think a lot of great programmers got that way precisely because they've always been bad at communicating with humans.  They were ostracized as children, and bonded early to computers as an alternative.  To get stuff through management, it's not just communcication -- you have to sell yourself and your ideas.  Well, not everybody is a good salesman.  Those who are go into sales and make a whole lot more money than techies.  JMO/YMMV

Morgaine Dinova wrote:

 

Although poor management is common in all fields, the core problem in software isn't lack of understanding of software by non-software-types, but lack of understanding of software by everybody involved in the process, Alpha Programmers included.  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.

My opinion:  I think a lot of great programmers got that way precisely because they've always been bad at communicating with humans.  They were ostracized as children, and bonded early to computers as an alternative.  To get stuff through management, it's not just communcication -- you have to sell yourself and your ideas.  Well, not everybody is a good salesman.  Those who are go into sales and make a whole lot more money than techies.  JMO/YMMV

John Beetem wrote:

 

Well, not everybody is a good salesman.

Very true. Engineers also often have a way of seeing the facts quite clearly, whether they like what they see is a different question.  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

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..."

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.

Dilbert showed why this is a dangerous idea on 21 April 1996: http://dilbert.com/strips/comic/1996-04-21/

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.