Intuition and design

So I was writing about intution, and somehow got sidetracked into how not to do ranking. Like a review of a game where the reviewer would judge the game on 5 different aspects, game play, sound, story, graphics etc. and then compute a final score based on fixed weights. How you'd fit a smash hit like Minecraft into that, I don't know.

What I really wanted to talk about was design.

Software development is full of design decisions. How do we present the information to the user? How do we let them act on it? How much to show, how much to hide?

How do we structure the code internally? What data do we store, how do we model it, how much do we capture? What other software do we build on?

What interface do we provide to other software developers?

It's a sea of decisions. Although it can be helpful for analyzing some outcomes, you can never hope to get through this sea with logic alone. You can often make reasonable deductions that something is simultaneously a good and a bad idea.

This makes it hard to discuss and evaluate these decisions. Often, we do not have the words, and even if we had, the actual components involved may be interrelated in such a complex manner that you'd never get anything out of studying them directly. You'd have to condense this complexity into something simpler, a process which may take much longer than the design process itself. And in simplified form, you can't be sure deductions are still valid.

So we're left with the intuitions we train for ourselves.

In other words, a prime concern of a software developer should be training this intuition effectively, i.e. input good training data with valid, confirmed outcomes - this works in this situation, this doesn't.

The main road to wisdom in programming, as in other crafts, I believe, is learning by doing. So experimenting or playing around if you wish, and seeing what happens. Not just in a strictly scientific sense where the experiment is artificial and controlled. It may be as simple as recognizing a common problem, working out a possible solution and implementing it and watching it unfold.

Sometimes you can take a shortcut by learning from others. There are various ways to go about this. Reading literature, or source code, or asking questions, or getting them to comment on your work. It's mostly about basic curiosity. Typical developer chat when someone is talking about something new they've done circle around how they made it work and what problems they encountered.

But the annoying thing about learning from others is, again, that it can be hard to talk about these things. Design decisions change when the details change. Sometimes minutia can decide whether one model is better than the other. How do you communicate this effectively? The person you are talking doesn't understand your problem completely. You don't understand the situation the other person was in either. So how do you know that the advice is correct?

I think this is here analytical skills are important. You always have to be sceptical, train your intuition into recognizing discrepancies and evaluate what context causes something to be judged to be good or bad.

For instance, if someone you know to have developed a sound intuition about a certain area find an idea of yours to be cause of alarm, you'd be a fool to ignore it. But unless you possess the same intuition about the problem, it can be hard to deduce exactly what causes the alarm and whether it's a problem in the context.

Frustratingly, it can also be hard to explain the root cause on the spot. Often, there is no explanation in the intuition. And examples can be hard to think up. I've sometimes been asked for an opinion, found cause for alarm but haven't been able to figure out why until several years later. I know that because those alarms haunt me for years, making me feel like a grumpy old man seeing ghosts everywhere.

One example I have is that of software you depend upon, as I touched upon in my previous entry. Over the years, I've come to the conclusion that some dependencies serve you exceedingly well, and others serve you hell.

Probably the hardest part of design is designing for the future. We never know what happens. Still, careful design mitigates the risks.