I've been saying for years that the future will not begin until the average Joe is able to program his computer. I know, I know - it's a convenient time to mention it. But those of us who make our living as programmers can get tired of being the go-to guys for computer issues. For my part, I find it embarrassing - and not just that I'm treated with deference and respect for nothing other than a minimum comfort with these machines. Rather, I completely understand the frustration of subordinating one's sentience to a stupid configuration ritual or opaque interface construct that by all rights should be conforming to me. Yet my generation is supposedly more advanced because we've learned how to click on "How High?" at the "Jump!" prompt. By the same token, my industry isn't exactly falling over itself to make these machines more human.
Upon reading Douglas Rushkoff's Program or Be Programmed, however, the annoyance has transformed to concern. The vast potential of our networked culture lies not in figuring out what the computer wants as much as figuring out what we want. Because as we tailor our wants to the available choices presented us by software, as we conform our lives and attention spans to the demands of the network, as we learn the new social dynamics of massive connectivity and anonymity, we aren't just adapting to inevitable realities of our times. We are just as assuredly adapting to the strategies of the business interests that have massive capital invested in leveraging the biases of these systems in which we too often passively participate.
Read more...
You can inspect the software that generates this blog on Github. I borrowed heavily from one developer to integrate Haml with pagination into Jekyll. It took a while (like all night) but it works. Tests are failing all over the place, though, so fork with caution.
Creative Destruction in Software Development
As design becomes more critical to software, programmers must find new challenges to realize user value
I've been thinking a lot lately about the relationship between front-end design and programming in software development, and this article hit me at just the right time (thanks for tweeting it, Wren!). Basically, Allen argues that as programmers become more productive, more resources get spent in the indeterminate and creative tasks of design than in the increasingly well-understood and less error-prone tasks of programming. I'm generally inclined towards his idea of a designer-driven industry, because I'd love nothing more than to spend my time exercising my artistic side. However, I think he gets a few things mistaken, because the state of our industry is not as cut and dry as he makes it out to be.
It would be impossible to positively address Allen's larger point without pointing out the elephants in the room. Yes, I laughed out loud at the mention of cookies as a data store. But the biggest pachyderm has to be the paltry sample size for such a sweeping conclusion. One project does not an industry trend make. This guy works with Microsoft frameworks; surely he's seen bigger, more involved projects than the one he describes as spending more time in design than in development. The more complex the functional requirements, the more time spent implementing that functionality. That takes time, and productivity can only shave so many man hours off an enterprise project.
Any well understood problem and solution will be faster to implement than one that takes a lot of planning. In the web world, we developers spend a lot of time developing the same basic applications over and over. While they don't all have the same function to the user, the relationships between the data entities on the backend are often pretty damn similar. How many of us build apps with account models? How many have entities that aggregate other entities? The reason ActiveRecord can model these joins and finds so well is because there aren't too many permutations of the data relationships in the database-backed web app industry.
Read more...
