More Compromises

I've written before about the importance of finding non-compromise solutions to problems. Well, here are a few more trick questions to ponder.

Who can you trust?

You will probably find that your answer to this question puts you in one of the following two groups. (You might be surprised to find that the other group really does exist, completely disagrees with your group, and is just as popular as yours.)

1. Trust must be earned. You won't trust someone to do something correctly until they've demonstrated their ability to do it. Once they've earned your trust, you'll usually trust them automatically to do that job in the future. But that doesn't mean you automatically trust them to do a different job, and so on.

2. Trust is transitive. If a person is in a position of authority, you trust them implicitly. If a person is trusted by a person with authority over you, then you trust that person as well. For example, someone who works for a manager that your own manager trusts would be trusted by you automatically, so you really don't have to worry about whether they'll do a good job or not; that's really someone else's problem to worry about, and you can safely assume they're handling it.

The second solution is short-term efficient. The first solution is long-term resilient.

I think I see the non-compromise solution to this one. Do you?

Brilliance vs. Repeatability

Another question that has come up recently has been the question of repeatable processes versus the flash of brilliance.

In many cases, there isn't much of a compromise between the two. A really great novel is never written using a repeatable process (although pretty good mass-produced junk fiction can be and is). Meanwhile, a widget factory runs on repeatable processes, and doesn't require much brilliance once it gets going. (Hopefully there was some brilliance in the original widget design.)

Software, however, just makes a mess of things.

You could summarize the mess as the never-ending conflict between "Software Engineering" and "Computer Science." Software Engineering claims that software can be created faster, better, and more reliably if you can just define repeatable processes and hire a bunch of code monkeys to implement those processes. For some things, like banking applications and warehouse management software, it works: well, at least it works better than trying to do the same thing without your repeatable processes.

Computer Science, on the other hand, is all about the flashes of brilliance and the "aha!" moments. (You might say the same about science in general, but most scientific research nowadays, outside of universities at least, is more about the repeatable processes than the brilliance.)

The really great stuff that we love about computing requires brilliance. The guy who figured out how to do the iPod user interface, or the person who realized that data structures could have functions encapsulated in them, or the person who invented the superposition operator in perl: those people are the ones who really make all our lives better, even as the rest of us try to repeatably write working programs in perl.

Unfortunately, it seems that two totally different social structures are needed to produce repeatability versus brilliant insight. A structure that encourages repeatability will stifle creative insight; but a structure that encourages creativity produces non-repeatable results, almost by definition.

I don't know the non-compromise answer to this one, but I do know the form of the solution: you want a process that repeatably produces brilliant results. If you could do that, you would be unstoppable.

But what on earth would you do with that much output?