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:

 

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

I would guess that someone who has mastered Universal Turing Machines understands the equivalence of instructions and data a whole lot deeper than I do

I'll go a bit out on a limb and say I don't think the equivalence of instructions

and data is necessarily fundamental to computer science.  I agree with you

that when debugging C, you will often see the machine fault when it tries to

mistakenly execute data.  But that's to some extent an artifact of C's broken

abstraction model.  You don't often see that happen say in Java.

C for example uses pointers in places where it's completely unnecessary,

such as passing a parameter by reference.  Pascal and similar languages

treat reference parameters at a higher level of abstraction, eliminating the

need for pointer syntax.  And stray pointers are probably the most frequent cause

of machine faults.  I think it's been said that pointers are to data what gotos

are to code. 

Computer scientists should understand the difference between value semantics

and reference semantics, but shouldn't fundamentally need to understand about

machine faults due to mistakenly trying to execute data.

coder27 wrote:

 

... I agree with you that when debugging C, you will often see the machine fault when it tries to

mistakenly execute data.  But that's to some extent an artifact of C's broken
abstraction model...

Nothing wrong with C's abstraction model.  IMO you just need to regard C as a portable assembly language that uses high-level notations.  When people think of it as a high-level language, that's when trouble begins.

C for example uses pointers in places where it's completely unnecessary,

such as passing a parameter by reference.  Pascal and similar languages

treat reference parameters at a higher level of abstraction, eliminating the

need for pointer syntax.  And stray pointers are probably the most frequent cause

of machine faults.  I think it's been said that pointers are to data what gotos

are to code. 

Well, when processors give me higher-abstraction instructions I'll think about dropping pointers and gotos.  As long as CPUs let me use registers as memory addresses and provide jump instructions I'll keep using them, because they work well if you use them properly.  You do want to master the basics before using them, but IMO it's silly to leave training wheels on a bicycle forever.  JMO/YMMV

> but IMO it's silly to leave training wheels on a bicycle forever.

It all depends on what the cost is.  If protecting yourself from

machine faults is nearly free, for example because your higher

level language enforces its abstraction model, then why not.

Parameter passing and array indexing are inherently high-level

abstractions that although they will be implemented with machine-level

code, they need not use machine-level pointer syntax.

The equivalence of code and data was a factor early in the history

of computer science, when it was believed that self-modifying code

was important, especially in AI where machine learning was thought

to require "rewiring" the brain. And LISP was ideal for self-modifying code. 

Since then, self-modifying code has fallen into disfavor, especially

with viruses taking advantage of executable stack pages in certain OS's. 

So I think the trend in CS is to as much as possible keep code and data

separate.  They can each have their own memory pages, with code pages

being read only, and data pages being non-executable. They can even have

their own separate caches in a harvard architecure.

John,

Nothing wrong with C's abstraction model.  IMO you just need to regard C as a portable assembly language that uses high-level notations.  When people think of it as a high-level language, that's when trouble begins.

You are entirely correct that if C is regarded as a portable assembly language, then it's abstraction model isn't broken.

But it's tempting for people to assume that C's variables and other abstractions are just like any other language's,

and as you say, that's what causes trouble.  I'm sure none of the following is news to you, but others may find it interesting.

I remember my first visit to a pediatrician where he did a reflex test by tapping a rubber hammer

on my knee.  I thought something's not right here.   My model of how the knee was supposed to work

was that the brain should control the knee.  I tried real hard when he tapped the other knee to kick

him with the wrong leg.

Then I was over at a friend's house and his dad was working on their car, with the engine idling

and the hood up.  My dad wasn't a mechanic and so I had very little understanding of how things

worked under the hood.  My friend's dad grabbed the throttle linkage attached to the carburetor

and revved the engine, much to my surprise.   I thought something's not right here.  There's nobody

sitting in the driver's seat, but the engine is only supposed to rev up if the driver presses the gas pedal.

Then I learned an early version of Fortran, and needed to convert a character from upper to lower case.

I found out that you could do it by declaring an integer array after the character variable, and index the array

with a negative index to obtain the integer representation of the character, and add 32 to convert to

lower case.  Something didn't seem quite right about that either.

Then I learned Pascal, where this trick was neither possible nor necessary, because array indexing

was checked, and there were intrinsic functions for converting characters to integers and vice versa.

This seemed like an improvement, although there was still a trick available of using a variant record to

subvert the type system.

In most high-level programming languages that have variables, a variable has associated with it a

value, and the fundamental rule of the abstraction model is that the value doesn't change except by

assignment to that variable, or by assignment to a parameter that is an alias of the variable.  In C,

on the other hand, a variable has associated with it an address, and the value stored at that address

can be changed by just about any code in the program, because it's trivially easy and common to

get hold of addresses and do arithmetic on them.   This makes it difficult to reason about

the behavior of a C program, whether the reasoning is done by a human or by an optimizer trying

to improve the code, or by some sort of static analysis tool trying to prove properties of the code.

coder27 wrote:

 

Then I learned an early version of Fortran, and needed to convert a character from upper to lower case.

I found out that you could do it by declaring an integer array after the character variable, and index the array

with a negative index to obtain the integer representation of the character, and add 32 to convert to

lower case.  Something didn't seem quite right about that either.

Very dangerous, since a different compiler or version might allocate the variables differently.  Much better to use EQUIVALENCE to ensure that arrays and variables are allocated on top of each other the correct way   Back in the 1970s I used EQUIVALENCE to create an arrays that were numbered from 0 instead of from 1.  I was writing an FFT and the algorithms were much simpler with arrays numbered from 0.  Fortran was actually a pretty good language for FFT at the time -- it was the only available language that had COMPLEX as a built-in type with built-in operators.

Then I learned Pascal, where this trick was neither possible nor necessary, because array indexing

was checked, and there were intrinsic functions for converting characters to integers and vice versa.

This seemed like an improvement, although there was still a trick available of using a variant record to

subvert the type system.

Variant records are a fine example of why a practical language should not be too restrictive.  You sometimes do need to bend the rules, and it's better to provide a well-defined way to do it that makes clear to someone reading the code that's you're bending the rules.

At one time I used to do a lot of programming in Pascal/VS, which was an excellent IBM mainframe extension of Pascal that allowed separate compilation of source files.  Unfortunately, it did not have a mechanism for function pointers, so when I needed to write a logic simulator I had to use C... K&R, before the ANSI improvements like function prototypes.  Awful C implementation, with 100 messages per syntax error

In most high-level programming languages that have variables, a variable has associated with it a

value, and the fundamental rule of the abstraction model is that the value doesn't change except by

assignment to that variable, or by assignment to a parameter that is an alias of the variable.  In C,

on the other hand, a variable has associated with it an address, and the value stored at that address

can be changed by just about any code in the program, because it's trivially easy and common to

get hold of addresses and do arithmetic on them.   This makes it difficult to reason about

the behavior of a C program, whether the reasoning is done by a human or by an optimizer trying

to improve the code, or by some sort of static analysis tool trying to prove properties of the code.

Modern C compilers do an excellent job of optimization.  As I understand it, if you use the address of a variable then the compiler can no longer assign that variable to a register (since registers don't have addresses in the most common computer architectures) and your performance will suffer.  If you willy-nilly increment and decrement pointers to access nearby variables, that's not defined by the semantics of the language so it's not necessary for the compiler to figure out what's the right thing to do.  Static analysis tools will give warnings about things like that, as well as warnings about many other things -- I've heard they produce lots of false warnings, and each static analysis tool generates different warnings for the same source code.

My general PG-13 rated comment about C and Asm versus "safe" programming languages like Basic is that it's a question of how many layers of condoms you want when programming.  If you don't use "safe" languages, the language won't protect you from unexpected negative consequences, and you'll need to be careful in other ways.  But it can be a lot more fun to program in "unsafe" languages, and a lot more satisfying

Very dangerous, since a different compiler or version might allocate the variables differently.  Much better to use EQUIVALENCE

Yes, that was my point, that languages that allow you to violate their abstraction models

are dangerous.

Awful C implementation, with 100 messages per syntax error

I've been noticing a lot of such cascading error messages in the Arduino forums when

for example there is a spurious semicolon before the opening '{' of a function.

http://www.element14.com/community/thread/10083?start=1138&tstart=0

Modern C compilers do an excellent job of optimization.

But the optimization suffers due to the availability of untyped memory operations

such as memcpy and memmove:

http://gcc.gnu.org/onlinedocs/gccint/Memory-model.html#Memory-model

and the difficulties of type-based alias analysis in such cases:

http://gcc.gnu.org/onlinedocs/gccint/Alias-analysis.html#Alias-analysis

But it can be a lot more fun to program in "unsafe" languages, and a lot more satisfying

you can also waste a lot of time debugging that way, because errors that would

otherwise be caught at compile time or in a run-time array bounds check, 

can turn into mysterious run-time behavior where evidence of the error may

not show up until long after the program has gotten off track.

coder27 wrote:

 

But it can be a lot more fun to program in "unsafe" languages, and a lot more satisfying

 

you can also waste a lot of time debugging that way, because errors that would

otherwise be caught at compile time or in a run-time array bounds check, 

can turn into mysterious run-time behavior where evidence of the error may

not show up until long after the program has gotten off track.

In my own programming, I rarely have bugs that could have been caught by run-time array bounds checking.  It's usually logic errors such as forgetting to handle an unusual case and the occasional dangling pointer, which is part of the price of writing code that uses (and reuses) linked data structures.  My solution is to try to keep things as simple as possible, and it works for me.  One way to keep things simple is to use a language that's well-adapted to the problem, so you don't have to encrypt the problem to fit the programming language.

My general opinion is that if you have sharp programmers, you can give them sharp tools.  If you don't, then you either need to give them "safe" tools or replace them with sharper programmers.

John Beetem wrote:

 

My general opinion is that if you have sharp programmers, you can give them sharp tools.  If you don't, then you either need to give them "safe" tools or replace them with sharper programmers.

Some programmers are sharper than others, but there are no human programmers sharp enough to fully comprehend algorithmic and state complexity in any non-trivial software system.  The disparity between programs and human capability to understand complexity and track dynamic state is vast, many orders of magnitide.  We would need IQs in the thousands (maybe millions) to program without introducing errors, no matter how many decades we've spent mastering a language.

This is why the bridges of software engineering collapse around the world millions of times each day.  It's not that the vast majority of programmers are amateurs or that the education system has failed us or that programming is a cool craft instead of an engineering discipline.  Those things could be fixed.  The underlying problem of human capability mismatch cannot be fixed, as long as we continue along the present track.

And there is little sign of anyone looking for alternative tracks, at least in practical computing.

Morgaine Dinova wrote:

 

Some programmers are sharper than others, but there are no human programmers sharp enough to fully comprehend algorithmic and state complexity in any non-trivial software system.  The disparity between programs and human capability to understand complexity and track dynamic state is vast, many orders of magnitide.  We would need IQs in the thousands (maybe millions) to program without introducing errors, no matter how many decades we've spent mastering a language...

Excellent comments, Morgaine.

You've heard me talk about this before, so the following is for others following this thread.  I believe we have complex systems because it's easier to slap together a complex system out of parts that "ought to work together" than to  think carefully through a system -- and document it -- before getting so far into the implementation that it's impossible to make fundamental changes.  I have met way too many soi-disant software engineers who hate writing software (not to mention documentation), so they mash together inappropriate modules from Edsger Dijkstra knows where.  I have also met way too many engineering managers who want something quick-and-dirty now instead of doing it right -- and then re-doing it righter after learning from the first go-around.

C.A.R. Hoare says it best, IMO:

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.

Actually, IMO humans are quite good at working with complex things once they have come up with good notations -- textual and graphical -- to describe them.  However, the development of those notations usually takes decades or centuries.

Morgaine Dinova wrote:

 

Some programmers are sharper than others, but there are no human programmers sharp enough to fully comprehend algorithmic and state complexity in any non-trivial software system.  The disparity between programs and human capability to understand complexity and track dynamic state is vast, many orders of magnitide.  We would need IQs in the thousands (maybe millions) to program without introducing errors, no matter how many decades we've spent mastering a language...

Excellent comments, Morgaine.

You've heard me talk about this before, so the following is for others following this thread.  I believe we have complex systems because it's easier to slap together a complex system out of parts that "ought to work together" than to  think carefully through a system -- and document it -- before getting so far into the implementation that it's impossible to make fundamental changes.  I have met way too many soi-disant software engineers who hate writing software (not to mention documentation), so they mash together inappropriate modules from Edsger Dijkstra knows where.  I have also met way too many engineering managers who want something quick-and-dirty now instead of doing it right -- and then re-doing it righter after learning from the first go-around.

C.A.R. Hoare says it best, IMO:

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.

Actually, IMO humans are quite good at working with complex things once they have come up with good notations -- textual and graphical -- to describe them.  However, the development of those notations usually takes decades or centuries.

John Beetem wrote:

 

Actually, IMO humans are quite good at working with complex things once they have come up with good notations -- textual and graphical -- to describe them.  However, the development of those notations usually takes decades or centuries.

It's interesting (or perhaps sad) to contrast that with the typically short  timescales of product and company planning in the commercial software world.  One might be tempted to suggest that open source could be the answer, since it doesn't end-of-life code with quite the same degree of profit-oriented ruthlessness, but alas even open source programs bit rot and stop working owing to dependencies and changing architectures.

The long-term view just isn't there, and may not even be possible.  Things change, it's part of progress.  Whatever solutions we come up with for the software crisis, they'll need to be able to cope with the current state of technology.  I very much doubt that refinement of languages or written code over ages will help much.

Morgaine Dinova wrote:

 

John Beetem wrote:

 

Actually, IMO humans are quite good at working with complex things once they have come up with good notations -- textual and graphical -- to describe them.  However, the development of those notations usually takes decades or centuries.

 

It's interesting (or perhaps sad) to contrast that with the typically short  timescales of product and company planning in the commercial software world.  One might be tempted to suggest that open source could be the answer, since it doesn't end-of-life code with quite the same degree of profit-oriented ruthlessness, but alas even open source programs bit rot and stop working owing to dependencies and changing architectures.

 

The long-term view just isn't there, and may not even be possible.  Things change, it's part of progress.  Whatever solutions we come up with for the software crisis, they'll need to be able to cope with the current state of technology.  I very much doubt that refinement over ages will help much.

Open source certainly helps, since it's not subjected to the limitations imposed by having to make money

Ars longa, vita brevis.

John Beetem wrote:

 

Open source certainly helps, since it's not subjected to the limitations imposed by having to make money

Unfortunately open source + free software is not fully isolated from the ill effects of preoccupation with money, short-term "product" focus, business planning and corporate competition.  Although individual projects may be created and developed by one or a small number of non-commercial and wholly altruistic enthusiasts, as soon as a project blooms into a global community resource it gains contributors with different needs and aspirations, many of them in direct support of business requirements and a focus on product and competitive advantage.

Open source code inevitably gets modified to support the latest devices or architectures, which typically undoes any previous validation that may have been done on it.  New drivers or patches are often added by corporate developers for whom getting support for a new gizmo is part of their jobs, but who will generally not continue to support their changes once those gizmos have been EOL'd in the company product cycle since they will not be paid to do so.  And unless they are exceptionally community-minded, they'll not be going out of their way to create generic infrastructure that supports their competitors, but instead focus on providing best support for their own requirements as their main priority.

So, open source doesn't exist entirely within an isolated collaborative space as is sometimes portrayed.  Even with everyone doing their level best and not having hidden agendas nor being deliberately evil, the nasty realities of the world outside FOSS idealism do intrude and mess things up to some degree.  Old code that is perceived as crufty is often removed purely to keep the more modern code sane, which means that honing code to a high state of reliability and trustworthiness over long periods of time just doesn't happen --- it bit rots or gets modified long before then, so validation and long-term stability just isn't useful or even possible in practice.

This is why I say that any solution to the software crisis cannot come from the "decades or centuries" that you mentioned, not even in FOSS.  It will have to be applicable to the code that exists at any given point in time or it won't be addressing the problem.

Morgaine.

Morgaine Dinova wrote:

 

John Beetem wrote:

 

Open source certainly helps, since it's not subjected to the limitations imposed by having to make money

 

Unfortunately open source + free software is not fully isolated from the ill effects of preoccupation with money, short-term "product" focus, business planning and corporate competition.  Although individual projects may be created and developed by one or a small number of non-commercial and wholly altruistic enthusiasts, as soon as a project blooms into a global community resource it gains contributors with different needs and aspirations, many of them in direct support of business requirements and a focus on product and competitive advantage...

Good points.  However, I would say that FLOSS (Free-as-in-Liberty Open-Source Software) generally benefits from participation by for-profit entities as long as the software uses a copy-left license.  Yes, money-driven entities will want to add code for their own purposes, but if they want to use immature FLOSS for serious purposes they'll find bugs and they'll be required by the license to publish the fixes to those bugs.  The rest of the FLOSS community can scoop up the bug fixes and improve the quality of the software.  It's very hard for an individual developer or even a small team to catch and fix everything, so having people paid to help is usually beneficial.

Example number 1 is obviously Linux.  It has grown amazingly over its lifetime, both in use and... in size.  I think of Linux as a terrific mainframe OS kernel, and when you think of it that way then its size isn't so shocking.  I think there's room for a light-weight personal computer OS, but I think we'll have to wait for Microsoft to complete its self-destruction first.  I don't think the wait is going to be long -- they seem pretty eager.

Linux benefits from having a foul-mouthed benevolent dictator to enforce quality, and from early adoption by IBM who defended Linux from early attempts to destroy it.

Example number 2 is Open Office.  That's a good example of a project that had to "fork it" to remain FLOSS.  I agree with RMS that you can't get the benefits of open-source software without the Four Freedoms, because otherwise corporations will take a snapshot of OSS and then keep all improvements to themselves.  It will be interesting to see how long Open Office stays around versus Libre Office.

John Beetem wrote:

 

I have met way too many soi-disant software engineers who hate writing software (not to mention documentation), so they mash together inappropriate modules from Edsger Dijkstra knows where.  I have also met way too many engineering managers who want something quick-and-dirty now instead of doing it right -- and then re-doing it righter after learning from the first go-around.

My experience is that a large proportion of software engineers actually like writing software, or at least did at some point.  But anyone who's done a couple of projects will have seen the pattern of the clueless engineering managers who just won't listen and will have quickly become jaded to the whole process.  They know they're probably going to have to do at least a couple of ground-up re-writes due to whatever daft managerial decisions get imposed.

If they learn anything the first time round it should be to never listen to the manager!

selsinork wrote:

 

My experience is that a large proportion of software engineers actually like writing software, or at least did at some point.  But anyone who's done a couple of projects will have seen the pattern of the clueless engineering managers who just won't listen and will have quickly become jaded to the whole process.  They know they're probably going to have to do at least a couple of ground-up re-writes due to whatever daft managerial decisions get imposed.

 

If they learn anything the first time round it should be to never listen to the manager!

This is an interesting discussion that I've been lurking on with some interest. I think everyone makes valid points, and I think that any language is the wrong language to use when it is used wrong. Java (my language of choice), which many touted as being the answer to many people's problems, still has a lot of problems inherited from C and C++, 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.

Speaking from my own experience, deadlines are necessary, you need something to focus the mind and finish up. But as the deadline looms, you have to make short term compromises that tell yourself you will come back to at a later date, and then don't because after the deadline has passed you have new work to work on. Those compromises, or the the code that is built on those compromises, cause problems further down the line. Good commenting or peer review can deal with this, but too often, neither happen.

The real problems arise when the people setting the deadlines are focussing too much on the short term. Sure, it makes good business sense to minimise your spend, but all too often PMs decide on the quickest or cheapest solution offered to them, without caring about the effects this causes. "Act in haste, repent at leisure". Quick and dirty solutions often cost a lot more in the long term than the slower, better solution, but some engineers have a terrible time trying to persuade a PM of why they should get 8 weeks to do a solution when a Q&D one can be done in 2. A PM in a previous job once said to me "Do the quick and dirty solution, but do it without writing the bugs". These days I show people the iron triangle.

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. Bad coders, wrong choice of language, poor management decisions, quick & dirty solutions, sloppy testing, the list goes on and on. The trick is to accept that there will be defects, and making sure that none of them break functionality or cause a terrible user experience. A good iterative QA cycle is essential for good software.

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.

I think it's as important to teach young coders how to deal with bad managers as it is to teach coders how to code.

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.

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