Complexity and Confronting
Posted: February 2, 2011 Filed under: General 10 CommentsIn 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.
- USERS
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.
- DOCUMENTATION
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.
-Max
Theta Code 
All of these are strong points about what programmers do wrong, but really, they’re all shades of the last problem: You don’t know something, so you invent something to fill the gap.
As a side note, not needing to DEAL with user requirements is part of why I find it so nice to work on projects which really ARE just for me. Since I am the user, it’s not actually bad to substitute myself for the user. 🙂
That is absolutely true. 🙂 The inability to confront the unknown is the *very first* non-confront that happens with almost all programmers.
Hahaha, yes, it’s always the best to work on projects that you yourself are a user of. That’s one of the reasons that I love working on tools for programmers, like Bugzilla–because I do know what programmers need and want. It’s still nice to go out and talk to some other people once the project becomes successful, though, so that I start to have a broader idea of what’s needed.
-Max
Yes, confront is where the whole process starts to break down. Because that is where the whole communication process begins – with the ability to face up to the person or subject. A friend of mine once resolved an accountant’s particular problem by drilling him on confronting his adding machine. He stopped making errors with that machine.
But whenit comes to programming, the whole comm formula applies. The programmer is running a pretty complex communication. He’s trying to communicate something to some users in the future whose actions he is asked to predict. That communication is not his own actually but is a fairly technical communcation from a field he may not be expert in (eg. insurance work). And he also needs to communicate to other programmers. It’s a lot to confron, but he needs more than just confront. He needs to be able to own the communication (not just cut and paste code as you say). I well remember the shock one of my peers got when I gave him some of my code to modify. The program was a very basic remote management package for a pc operating over LU6.2 (a defunct networking protocol). Written in C, every routine had plain English descriptions of what the code did with all dependencies clearly marked. He had never seen anything like it but it’s something aScientologist would naturally do. Communicate as best we can!
Hey Steve! Very true, the whole communication formula would apply, including intention from the original programmer resulting in an understanding by the other programmers, finally concluding with an understanding by the user.
I wouldn’t try to predict the actions of users, though–I prefer to know the actions of users by perceiving those actions.
It seems pretty sane and standard practice to accurately document what the heck functions are for, particularly in a language like C that can get a little obscure at times. I mean, of course, it wouldn’t be like assembly where you document every line–programmers should be able to read code. But without some general framework description, it can definitely be hard for one programmer to fully understand what another was doing.
-Max
I disagree with the author’s premise.
As one who as been programming for decades, and ofen with extensive interaction with users and customers, my experience has been that mostly users and customers don’t know or understand what they really need, or ofen even what they really want.
It is the use of imagination and the assessment of user input (what the author calls ‘opinion’) which is precisely necessary to determine the real needs and create a system which addresses those real needs.
That many delivered systems do not address real needs is a failure to fully understand the actual and underlying needs of users, as opposed to their stated desires.
None of this implies that a programmer should decide what people should want or need; quite the contrary, requirements analysis and determination is the hardest and subtlest part of software developement, and the one where most failures begin, and those failures are shared between developers who are too passive and timid to truly confront the often misguided expressions of users’ needs, and users who are too presumptuous or too impatient to think more deeply and respond to repeated questions.
Of course, drawing out true requirments from users is an art, which requires tact and grace, precisely because many users resent having to clarify their thiking.
So maybe, in a sense, I do agree with the author in a way. Again I’m not saying programmers should predict the future or substitue their own ideas; on that point the author is correct.
However, blindly doing whatever the customer asks for, without some critical analysis and validation, is irresponsible.
Hey Michael. I fully agree with you–it is necessary to actually confront what users really do, not just what they say. I would never implement something just because a user requested it; I would always attempt to confront the actual activities of the user, and confront many different users at that.
-Max
I agree with all you say about our shortcomings as programmers.
I think there is also often a lack of confront on the part of users so that they don’t know what the requirements are.
I once had a system 90% done and about to deliver when suddenly all the users got fired and the new guys who came in to replace them took one looks at the system and said “why did they ask for that?” Turned out that the first lot of users weren’t confronting their area (hence they got fired) and so they had come up with bogus requirements.
So it’s not always all down to us when it comes to requirements gathering.
However, I’m totally with you on ugly complex, crazy code. That comes from people not only not understanding requirements but also from not understanding and misunderstanding the language they are using and the underlying concepts that the language and its constructs express.
Anyway, nice article.
Yeah, actually I think partially what you’re talking about with users is the subject of another blog that I have brewing in my mind right now for Code Simplicity, about how users must only supply and describe the problems they want to solve, and must never describe solutions. Reversewise, programmers must only provide solutions and never imagine or provide problems to solve.
I think that ultimately it *is* up to us, though–but the trick is that it’s up to us to know *how* to coax the proper description of a problem out of a user, or to actually go and observe their environment and (with other *factual* data from the user about their life) decide for ourselves what their problem is.
I am *totally* with you about the understanding thing. I actually wrote up a full blog about just that: http://www.codesimplicity.com/post/why-programmers-suck/ — I feel like this point, the confront point, is the first missing undercut to that blog, though.
And thanks for the compliment on the article! 🙂
-Max
/* Begin Comment;
I appreciate Michael’s comments; as an old timer myself (1980’s programmer), it seems like not much is new on the human side of computing. The same dilemma between users and developers. May I put forward that ‘the dilemma’ which is at the core of the ‘confrontation’ is not restricted to programmers and users, but represented in society in general .
As an elite programmer, I can remember all problems were due to users, so much so that I referred to them as ‘PEBCAK’, Problem Exists Between Chair and Keyboard. It has taken some years to mellow that approach, moving from understanding to overstanding. End Theta.
End Comment; Jamzen,Cousins Cove,Jamaica */
You nailed the it, Max. The full description of what I was groping for just earlier. I might suggest one more area of non-confront: other programmers – although this may be a sub-category of “users”. As you’ve mentioned elsewhere, writing code “that works” is one thing, writing code that another programmer can understand is something entirely different!
Thanks for the excellent article.