Complexity and ConfrontingPosted: February 2, 2011
In a policy letter of September 18, 1967 titled “COMPLEXITY AND CONFRONTING”, L. Ron Hubbard states:
To the degree that a being cannot confront, he enters substitutes which, accumulating, bring about a complexity.
The definition of “confront” being used there is a Scientology definition: “to face without flinching or avoiding” (that’s from the Dianetics and Scientology Technical Dictionary).
This is the no-holds-barred, fundamental explanation for why some programmers cannot produce simple systems. This is the underlying difference between the great programmer and the terrible programmer–the degree to which he can confront.
But what is it that these terrible programmers are not confronting that leads to these convoluted, awful systems that we all live with? At first, you might think that it’s the computer, the keyboard, the monitor–the simple, obvious things that are right in front of them. But all the programmers I know have no trouble confronting those things. In fact, many programmers are most comfortable facing a computer, and don’t avoid it in the least. And as L. Ron Hubbard says, people enter substitutes for things that they can’t confront, and programmers don’t substitute other things for their computer. In fact, they’re more likely to use their computer itself as a substitute for other things that they couldn’t confront.
So what are the things that many or most programmers can’t confront, that they enter substitutes for?
- PRESENT TIME
Many programmers cannot confront the present-time environment–not necessarily the space that they are in while they’re programming, but the environment that they are designing a system for. Programmers must design only for present-time, fully-known requirements that they have actually discovered by confronting the immediate, real environment that they are designing for. However, instead of this, most programmers enter one of two substitutes for present time: their imagination or opinion about the present time environment, or their imagination about what the future environment will be. In general, it’s much easier for a person to confront their own thoughts about something than it is to confront the actual thing. In software, though, this leads to disaster (and “a disaster” would be how I would describe nearly all of the modern software landscape, truthfully).
When a programmer uses their imagination or opinions about the present to design a system instead of confronting the current reality to learn what needs to be done, they design a system that does not actually fulfill their users’ requirements. This is why so many programmers think that “all first tries should be thrown away and re-written”–because they couldn’t confront the real environment, so the first system they designed wasn’t appropriate for reality. Then they delivered it to the users, and the users raised hell because the system was worthless or extremely problematic for them.
When a programmer imagines a future environment instead of confronting present time, they create a system that has features that (a) users don’t need, (b) is far more complex than it needs to be thanks to these unnecessary features, and (c) does not appropriately fit with the real future when it comes. Most programmers think that all large programs will have to be fully re-written at some point, but this is a false datum. These systems that “need re-writing” have been so heavily designed for an imaginary future that when the real future comes, the only workable solution is to throw away the mis-designed system and create a whole new one for the real present. It’s not that all systems need re-writing, it’s that almost every system is plagued by programmers who chose to confront an imaginary future instead of the real present.
Programmers are uniformly excellent at confronting machines, technology, and computers. However, far fewer programmers are excellent at confronting users–the human beings who use their software.
Now, there is a stereotype that all programmers have poor social skills, but I have found that in my experience this is not true. Most programmers are perfectly capable of having standard social interactions with other people. However, what many programmers do not confront is actually communicating with users about the systems they are designing. Much like with present time, instead of finding a user (or a lot of users) and talking to them, surveying them, etc., programmers will frequently imagine a user and then design the system for that imaginary user.
Sometimes this imaginary user is very much like the programmer themselves, or like one of the programmer’s parents. No matter who this imaginary user is or how intelligent the programmer is at creating them, though, they are not real. Only real users have real requirements–imaginary users have imaginary requirements that you should not be wasting your time on and complicating your system by implementing.
In fact, it’s not just enough to confront one user, but to design a truly sensible system, you have to confront lots of users. And you can’t just bunch them all up in a group and then imagine what that whole group of users thinks–you have to confront each person in that group of users individually, and communicate with them as an individual to discover the broad patterns and needs across these individuals that will assist you in designing an excellent system.
The number of programmers who just haven’t read the documentation on things is pretty astounding. Nearly everything there is to know about programming and computers has been written down somewhere, and all you have to do is read it. If you haven’t used some piece of a programming language before, then read its documentation before you use it. Simple.
The thing that most frequently gets substituted for reading the documentation is copying and pasting other people’s code without understanding it. That is, the programmer could have spent some time reading up on things so that they understood how to do it themselves, but instead they found some piece of code that “just works” and copied it into their system without having actually read any references about it.
This is less common than the other problems listed, but it’s still a pretty widespread issue.
- NOT KNOWING
This is actually a broader problem–probably the whole world has been messed up across billions of people and thousands of years by man’s inability to confront the fact that there are some things that he does not know. Instead of simply looking at something and saying, “I don’t understand that, let’s find out what it is,” people will invent explanations and then not investigate. For example, thinking “that person frowned at me, they must dislike me,” without ever asking that person if they actually dislike you. Many people will substitute an invented piece of knowledge like this instead of finding out the real knowledge, because it’s so uncomfortable to “not know” that they can’t do it for long enough to actually find out.
In programmers, I most frequently see this manifested as the assertion that they do know something about the future when in fact they do not. They are so uncomfortable with not knowing what is going to happen that they imagine a future and then design a system based on that.
The same problem happens with user requirements–it can take a long time to gather user requirements accurately. Until you’ve gathered them, you don’t know them. But that rarely stops programmers from saying that they already know what the users need and want. Often this escalates into arguments among several different individuals about how something should be implemented, when in reality all of those individuals have absoultely no solid evidence to support their arguments, but only their opinions. Their opinions were easy to confront, but admitting that they didn’t yet know the truth was hard to confront.
Before you can know something, you have to first admit that you do not know it.
There are probably other things that programmers could use some help confronting, too, but the above are the most major ones that I’ve observed across a broad range of projects and skill levels.
The solution here is to simply train programmers to face these things without flinching or avoiding them, and then you will ultimately have reasonable, sane, simple systems that don’t cause endless trouble for everybody.