The ways in which we cheat our users. The developers dirty lie.
It's been interesting watching Rebeca Murphy of yayQuery fame go through the shift from script kiddie to developer. To watch her exploration, under the bright lights, of the things all developers go through. I looked over her slides from the Boston jquery event (http://www.slideshare.net/mobile/rmurphey/functionality-basedorg) and was really hoping she happened upon something interesting in her travels. What she happened upon was MVC. She calls them mediators (controllers), views (views), services (models) under the guise of functionality based organization but in reality it's just plain old MVC. two things occurred to me while reviewing the slides. First, it seems a massive portion of most programmers thought process is devoted to not writing code. I see this everywhere. It's cloaked in various ways, such as mvc or abstraction, or dry, or agile but what it really boils down to is programmers don't like to write code. Were always looking for cleaner ways to implement, maintain, and refactor our code and our conceptual framework about application design. The larger portion of all tech blogs and conferences seem focused on this goal. And, having developed in some form or more for over two decades it's something I've come to assume is part of the life of a programmer. But here's the second thing that occurred to me. It's pretty much bullshit. Most web applications, and by most, I mean 99.5% don't end up being maintained in any long term way. Over half never make it to market. Of the half that do, many live on in their basic form for a while but never blossom into anything more than what they were originally developed to do. Then are replaced or negated. Those few which survive face massive change over time and likely are unrecognizable to the original developers. How much original code do you suppose exists in facebook or Twitter? The sad truth of our industry is we are navel gazers. We're hyper focused on architecture and implementation while project failure rates are astoundingly high. We massive efforts on learning, growing and improving how we do things and tell ourselves it's for the betterment of the applications. It's not. It's fear management. Big codebases are scary to the human mind. There's so much context required to have room to breathe and gaining that context requires a big psychological commitment on the part of developers. Bigger than were really comfortable with and so we look for ways to abstract out that complexity through patterns, systems and conventions. We spend inordinate effort battling reality because its too terrible to face. The reality is most modern web development is pretty simple computationally. Our tools have improved greatly and you don't require a CS degree to build most things we approach. However, what has sent changed is the scope of context. The mental demands put on developers to keep context outstrips our ability regularly and so we seek ways to lessen that strain via patterns and systems. At the end of the day though, what I've come to see after so long in the muck, is we can't find relief from contextual strain this way. Slice the problem into smaller and smaller chunks, till it appears manageable but in the end you still have the same amount of context to jam into your brain, only now it's wrapped in seven layers of abstraction and parsed out into numerous patterns you must have accurately and reliably implemented--but no one ever does, so we must double check our double checking. The problem of contextual complexity, or more succinctly, the amount of organized information about your problem domain, implementation and the layers spanning between them cannot be wished away. You can hide it, obscure it, parcel it, but you can't escape it. And in trying you spend vital mental energy that counts against both your capacity and your project resources. The resulting wreckage of our industry wide shirking of reality is developer burnout, massively missed deadlines and horrendous project failure rates. And one other tiny thing we forget in all this... The people who use our software, and their needs. the real consequence of our denial is that despite the brainpower, and tools, most software for most people is borderline unusable, or worse, fails to address their needs in ways that matter. To say nothing about the opportunity lost by not presenting users with software that enables them to exceed what we conceived for them in the first place. We love how mashups explode our concepts of two or more applications once joined, but ignore our app combined with each human that uses it is in fact a mashup. Each unique mind brings new possibility, but the way we fixate on implementation over experience we leave little room for use imagination and most often when we see their imagination poke through our app it's in the form of a bug, more mental weight. this observation I've made comes to you as just that. I offer no solution beyond perhaps raising the question of where our true motivations lie as developers. Ourselves, and our escapist tendencies when confronted with complexity (or more accurately contextual depth). I wonder what sort of apps we'd make if we spent less time on our fear of code and more on solving user needs. If we shifted our focus from a race away from spagetti code and extensibility and on to project completion, and deep mining of user need. There are probably many spelling and grammatical errors above, I wrote this unexpectedly long blog from my iPad and fighting it's spell checker and odd responses to my typing will remain as they sit as a sort of testament to what I said above.
