Most difficult programming explanation

Question

Recently I tried to explain some poorly designed code to my project manager. All of the manager classes are singletons ("and that's why I can't easily change this") and the code uses event dispatching everywhere that a function call would have sufficed ("and that's why it's so hard to debug"). Sadly it just came out as a fumbling mess of English.

Whats the most difficult thing you've had to convey to a non-technical person as a programmer? Did you find any analogies or ways of explaining that made it clearer?

Answer 1

Thread Synchronization and Dead-Locking.

Answer 2

1.) SQL: Thinking in sets, rather than procedurally (it's hard enough for us programmers to grasp!).

2.) ...and here's a great example of demystifing technical concepts:

How I explained REST to my wife

Answer 3

Spending time on design, and spending time on refactoring.

Refactoring produces no client-visible work at all, which makes it the hardest thing in the project to justify working on.

As a second "not client-visible" problem, unit testing.

Answer 4

I sometimes really have hard time explaining the concept of covariance/contravariance and the problems related to them to fellow programmers.

Answer 5

Avoiding Dead-Locking in a multi-threaded environment.

I cleared confusion by explaining it visually on a white-board, drawing out two parallel lines and showing what happens when the reach the same points at the same time.

Also role-playing two threads with the person I was explaining it to, and using physical objects (book, coffee mug, etc) to show what happens when we both try to use something at once.

Answer 6

How recursion works...

Answer 7

Convincing a friend that the Facebook application I developed really doesn't store her personal data (e.g. name) even though still displays it.

Answer 8

Why code like this is bad:

private void button1_Click(object sender, EventArgs e)
{
    System.Threading.ThreadStart start = 
        new System.Threading.ThreadStart(SomeFunction);
    System.Threading.Thread thread = new System.Threading.Thread(start);
    _SomeFunctionFinished = false;
    thread.Start();
    while (!_SomeFunctionFinished)
    {
        System.Threading.Thread.Sleep(1000);
    }
    // do something else that can only be done after SomeFunction() is finished
}

private bool _SomeFunctionFinished;
private void SomeFunction()
{
    // do some elaborate $#@%#
    _SomeFunctionFinished = true;
}

Update: what this code should be:

private void button1_Click(object sender, EventArgs e)
{
    SomeFunction();
    // do something else that can only be done after SomeFunction() is finished
}

private void SomeFunction()
{
    // do some elaborate $#@%#
}

Answer 9

There's really no right or wrong answer-proper for this... it's all experiences.

The hardest thing I have had to explain to a non-tech person was why he couldn't get to his website when traveling abroad but his family member that lived there (with a totally different provider) could get to it. Somehow, "Fail in Finland" wasn't good enough.

Answer 10

The most difficult concepts to explain to people I would label programmers as opposed to developers are some of the most core paradigms of object orientated design. Most specifically abstraction, encapsulation and the king, polymorphism and how to use them correctly.

Expanding on that is the level of complexity of explaining what Inversion of Control is and why it is an absolute need and not just extra layers of code that doesn't do anything.

Answer 11

The concept of recursion - some people get it really hard.

Answer 12

The importance of unit tests.

Answer 13

I had a fun case of trying to explain why a program wasn't behaving as expected when some records in a database had empty strings and some were NULL. I think their head just about exploded when I told them empty string is just a string with 0 bytes in it while NULL means unknown value and so you can't actually compare it to anything.

Afterward I had one nasty headache.

Answer 14

My most difficult question began innocently enough: my girlfriend asked how text is rendered in Firefox. I answered simply with something along the lines of "rendering engine, Gecko, HTML parser, blah blah blah."

Then it went downhill. "Well how does Gecko know what to display then?"

It spiraled from there quite literally down to the graphics drivers, operating system, compilers, hardware archiectures, and the raw 1s and 0s. I not only realized there were significant gaps in my own knowledge of the layering hierarchy, but also how, in the end, I had left her (and me!) more confused than when I began.

I should've initially answered "turtles all the way down" and stuck with that. :P

Answer 15

"Adding a new programmer a month to this late task will make it ship later. Never mind, read this book." (The Mythical Man-Month.) Managers still don't quite get it.

Answer 16

Trying to explain why code was executed sequentially at all. Seemingly this is not at all intuitive for some non-programmers (i.e. my girlfriend).

Answer 17

Why it'll take another four weeks to put this app into production. After all, it only took a week to do the rapid prototype. It "works" (or at least looks like it does) so I should be pretty much finished, shouldn't I?

Explanations that involve security, code quality (maintainability), normalized DB schemas, testing, etc. usually come off as a list of abstractions that don't have any visible effect on the app, so it's hard to explain what they really contribute to the project and why they're necessary. Sometimes analogies can only take you so far.

Answer 18

A lot of statements starting with "It's because in Oracle, ..." come to my mind.

Answer 19

The biggest hurdles are around "technological debt", especially about how the architecture was correct for this version but needs to be changed for next version. This is similar to the problem of explaining "prototype versus production" and "version 1.0 versus version 2.0".

Worst mistake I ever made was doing a UI mockup in NeXT steps UI Builder. It looked exactly like the end product would look and had some behaviour. Trying to explain that there was 6 months of work remaining after that was very difficult.

Answer 20

I was going to comment on Mikael's post, that some people just take the sequential programming and unfortunately just stay with that.

But that really means: two seriously hard to explain concepts:

• monads in haskell (usually starting with: "That's like a function that returns a function that does what you really wanted to do, but ...")
• deferreds in twisted/python ("That's like... ehhh... Just use it for a year or so and you'll get it" ;) )

Answer 21

C pointers

*i

&i

Answer 22

Why you do not need character correct index handling in most cases when you use UTF-8 strings.