are programmers "failures"?

[Don Shepherd]

I am reading a book about programming concepts of the IBM 1620 computer, written in 1962. The following two quotes are from this book:

"There is one quality that is common to all programmers: an astonishing ability to absorb repeated failure. This is because the 'first-time correct' program is extremely rare, and the word 'first' can be changed to 'second,' 'third,' and 'fourth' with the statement still true."

"The student is to be constantly reminded of two 'theorems' associated with computer programming which, unfortunately, have more truth than humor: Theorem 1 - Every program has at least one error. Theorem 2 - Every program can be shortened."

This was undoubtedly true in 1962; I can vouch for that! With all of the modern programming languages available today, is it still true in 2019?

[grsbanks]

As a programmer by trade I can say that this still holds true today.

However, to say that programmers are "failures" because they never get it right first time is perhaps a little harsh. What it does not convey is a programmer's ability to analyse the failure and put it right!

[Don Shepherd]

(03-23-2019 01:21 PM)grsbanks Wrote:  As a programmer by trade I can say that this still holds true today.

However, to say that programmers are "failures" because they never get it right first time is perhaps a little harsh. What it does not convey is a programmer's ability to analyse the failure and put it right!

Yes, I agree. The author didn't really call programmers "failures," he stressed that achieving the perfect program rarely happens the first time.

What I am really wondering is this: do modern programming languages make it more likely that a programmer will generate a correct program the first time? I suspect the answer is "somewhat, but not totally."

[mfleming]

(03-23-2019 02:01 PM)Don Shepherd Wrote:  What I am really wondering is this: do modern programming languages make it more likely that a programmer will generate a correct program the first time? I suspect the answer is "somewhat, but not totally."

There was an old joke about Ada that when you finally got the program to compile, it would work correctly! Seriously though, a subset of Ada called Spark with its associated tools is used in automotive and aviation safety-critical software development. I don't think any programming language itself can guarantee correctness. I'd say there's a close resemblance between the Correctness Problem and the Halting Problem.

~Mark

[cdmackay]

I liked the claim (Kernighan?) that debugging is twice as hard as programming. So if you wrote your program as cleverly as you could, then you are not capable of debugging it.

[pier4r]

(03-23-2019 02:01 PM)Don Shepherd Wrote:  What I am really wondering is this: do modern programming languages make it more likely that a programmer will generate a correct program the first time? I suspect the answer is "somewhat, but not totally."

Trivial ones, sure. But that would be true even before nowadays programming languages.

Examples:
- pick a low level language and add 1 to a variable.
- pick whatever language one is familiar with and let him do something trivial that he did thousands of times, like printing a statement
- and similar examples.

For each non trivial solution, that was not coded over and over by the person writing the program, it is unlikely it will work at the first run. Maybe if the person iteratively expands the program, coding and testing smaller parts of it before. But even in that case one can consider the full program, and therefore the entire process of starting from a small part of the program to then code it completely, and likely there will be an error somewhere. Even just a typo.

It is a layer 8 problem, as in many other cases.


Plus I think that such "failure" metric can be applied to every job that is not menial. So at the end humanity would be a failure applying the same metric.

[grsbanks]

(03-23-2019 07:49 PM)pier4r Wrote:  So at the end humanity would be a failure applying the same metric.

Looking at the political situation in several parts of the world, you're probably not far from the truth with that!

[Albert Chan]

I don't think programmers are "failures". It is just that computers are dumb.
It required every details, exceptions, fully spelled-out.

For example, recently in the Lua forum, people were discussing how to recognize end of a sentence.

Period after a space considered a sentence.
Last sentence may not have a period.
Ignore names with initials: say e. e. cummings
Need a database of abbreviation, say Mr., A.D.
Except, abbreviation happened to be end of sentence. Uh, how to tell ?
Period may be used for other purpose, say, decimal point, web address, ...

[Vtile]

(03-23-2019 11:24 PM)Albert Chan Wrote:  I don't think programmers are "failures". It is just that computers are dumb.
It required every details, exceptions, fully spelled-out.

For example, recently in the Lua forum, people were discussing how to recognize end of a sentence.

Period after a space considered a sentence.
Last sentence may not have a period.
Ignore names with initials: say e. e. cummings
Need a database of abbreviation, say Mr., A.D.
Except, abbreviation happened to be end of sentence. Uh, how to tell ?
Period may be used for other purpose, say, decimal point, web address, ...

Yes. You need to told the computer what is a sentence and what are the rules to form one in that particular language and only after that you can talk how to recognize one. In that point of time the project manager have thrown you out of the project because, well it is only a sentence so how hard can it be.

[toml_12953]

(03-23-2019 01:10 PM)Don Shepherd Wrote:  This was undoubtedly true in 1962; I can vouch for that! With all of the modern programming languages available today, is it still true in 2019?

You're only a failure if you give up. Most programmers (of which I am one) keep at it until the program runs correctly. Then they go back and optimize it. Of course there are usually time constraints. 1. The users want it NOW. 2. It's got to be ready to ship on Wednesday. NO EXCEPTIONS! 3. You have this other list of programs waiting. You can't spend too much time on just one. So it goes.

Failure? Nope. Look at baseball players. Hitting only 4 out of every 10 makes you a great player!

[Don Shepherd]

(03-24-2019 01:26 AM)toml_12953 Wrote:  Of course there are usually time constraints. 1. The users want it NOW. 2. It's got to be ready to ship on Wednesday. NO EXCEPTIONS! 3. You have this other list of programs waiting. You can't spend too much time on just one. So it goes.

Tom L, back in the early 1970's when I began as a programmer for a large federal government agency, the experience was somewhat different from what you describe. I was assigned to write and test a program that would run in batch mode on the Univac mainframe. There was no "user," per se. There was no test department also. It was my responsibility to write it, test it, and when I was convinced that it was ready, turn it over to production where it would be run 50 times, once for each state. That put a lot of responsibility on the programmer to make sure it was right, and I never recall any of my group's programs having to be rerun in production because an error was found after the production runs completed. That was a great environment for a beginning programmer.

I think programmers today don't have it that easy, unfortunately.

[Thomas Okken]

We certainly don't. We have Agile! I envy everyone who was able to retire before this idiocy started to spread.

[Don Shepherd]

(03-24-2019 03:30 AM)Thomas Okken Wrote:  We certainly don't. We have Agile! I envy everyone who was able to retire before this idiocy started to spread.

I just read Wikipedia on Agile. All I can say is "good grief."

[Garth Wilson]

Quote:Except, abbreviation happened to be end of sentence. Uh, how to tell ?

Put a second period after the one for the abbreviation. Otherwise it's especially confusing when the next sentence starts with something like a number, or a reference to a label, variable, etc. which is never capitalized, or which may change meaning if you capitalize it. That's also another good reason for two spaces between sentences.

So many things need many corrections to succeed. Consider even driving a straight road where you cannot be considered a failure just because you can't point the car in one direction and then let go of the steering wheel for the duration of the straight part of the road.

[David Hayden]

With today's programming languages, you can achieve a lot more in a few lines of code than you could in 1962. So even when a program doesn't work perfectly, it still does a lot. This means that there's a lot more reward for your effort than there was in '62.

Also, I think that writing a program from scratch is more like carving a statue. You'd never say that an incomplete statue is a "failure" and that artists endure days of failure before their product is done. It just takes time to get it right.

Quote:We certainly don't. We have Agile! I envy everyone who was able to retire before this idiocy started to spread.

Ain't that the truth!

Agile is sort of "how to fix software development as told by project managers."

• "It goes way off schedule!" We'll have short milestones
• "It doesn't work!" We'll creating working programs and keep modifying them till they're right
• "It doesn't do what the customer wanted!" We'll have frequent demos
• "We spent all our time designing!" We'll just build and modify until it's right
  

Agile is an awesome way to manage a Project file and a horrible way to manage software development.

When they implemented it in our company, I kept asking "what problem are you trying to solve?" We're a group of experienced developers who've worked together for 20 years. I never got an answer to my question. Fortunately, we've figured how to make it look like we're doing Agile while mostly carrying on as before.

[pier4r]

I think that Agile, and many other frameworks, is not intrinsically bad. It has two big flaws though.

(a) it is not really based on hard data. Rather on observations. Observations can produce apparently reasonable solutions, but that at the end of the day they are superficial and help no one.
(b) Even in the case the solution suggested is sound, it is poorly applied. For example, let's be honest, Agile as it core coincides with the "Plan do check act" framework and ultimately with the scientific method. You have an idea, you plan for it (do your hypothesis), you code and test it (do/testing), you collect the result and you do a review to improve the idea/implementation if needed. Then the next cycle happens.

The reality is that, at least for what I read all over the internet and I experience at work, Agile (or the like) is never implemented. It is more waterfall with standups.
There is never a review. And if there is, it is once 5 months after the project ended.
In the standups there is no really "hey I am stuck with this, does anyone have an idea?". People barely listen.
It is never "ok we are going to implement only those X features in the next cycle". Rather it is "do as much as you can, if possible tonight".
There is poor testing and collecting whether things works.
There is poor reuse of code across projects.
Etc....
It is a poorly implemented chaotic mess.

So my 2 cents are. Agile is not bad, although it may be a superficial framework. Rather I have never seen it implemented properly.

[cruff]

We use Agile at work, where I've found it mostly reasonable while fixing the easier bugs (problem reports), but less so for new design features or the really complex bugs. I once spent three weeks looking for a bug in some image processing code, had to come up with "tasks" to put on the Agile board to make it look like I was doing stuff. I'm still trying to come to grips with Agile after two years using it.

[Thomas Okken]

And what, once you have come to grips with Agile -- which never happens, by the way, witness the fact that every Agile apologist ever is always going on about how people don't understand it and are doing it wrong -- what exactly will you have achieved?

It made me laugh, and yet it is utterly typical, that even the Wikipedia page on Agile only credits it with making teams, well, more Agile. It's so boneheaded, you can't make this stuff up.

People have written software for decades before Agile. Every operating system in existence, every major piece of shrink-wrapped software, global information systems in business, finance, and science, all put together by people who had no name for what they were doing other than "coding" and "project management," and who, for the most part, knew to focus on results, and refrain from micro-managing each other.

Oh, how long ago it all seems. /rant off

[Claudio L.]

All those management systems add another layer to justify managers existence.
If your program doesn't work not only you have a bug in your program, now you also have a bug in your implementation of the Agile method, which was incapable of preventing the existence of the bug in the first place. Now you can have your coders chase one bug while managers chase the other... and everybody gets paid.

[Eddie W. Shore]

(03-23-2019 01:10 PM)Don Shepherd Wrote:  I am reading a book about programming concepts of the IBM 1620 computer, written in 1962. The following two quotes are from this book:

"There is one quality that is common to all programmers: an astonishing ability to absorb repeated failure. This is because the 'first-time correct' program is extremely rare, and the word 'first' can be changed to 'second,' 'third,' and 'fourth' with the statement still true."

"The student is to be constantly reminded of two 'theorems' associated with computer programming which, unfortunately, have more truth than humor: Theorem 1 - Every program has at least one error. Theorem 2 - Every program can be shortened."

This was undoubtedly true in 1962; I can vouch for that! With all of the modern programming languages available today, is it still true in 2019?

At first you don't succeed, try and try and try and try again.