Developer-centered Design

It is common practice to design software with the end user in mind. We call this user-centered design. Its primary concern is to create a system for end users that contains a kind of conceptual continuity, mitigating the pain of the unfamiliar. While it is no doubt crucial to consider the needs of the end user when designing a system, we also need to think about those of another type of user: the developer. After all, if a system doesn't contain some form of conceptual continuity in the way that it's built, developers will find it increasingly difficult to grow and maintain it. And because it will be difficult, they won't enjoy the process, resorting to quick and dirty solutions to avoid the fatigue that sets in when grappling with conceptual cacophony.

I would venture to guess that our brains release endorphins when they sense the patterns inherent in a conceptually continuous system. We like when we try new things and they work because they're similar to things we've done before. Once you master sending and receiving emails, it's not difficult to grasp the concept of replying and forwarding. Developing a system is (or should be) the same way; it should be clear how to create something new based on what you already have.

Developers and end users alike shouldn't have to "Read The Fucking Manual." You don't learn how to use software by reading about it; you learn by using it. And if it's a pain in the ass to use it, whether externally as an end user, or internally as a developer (or, worst case, both), people will just give up.