"software design" entries
Computing should enable us to have richer lives; it shouldn’t become life.
At a recent meeting, Tim O’Reilly, referring to the work of Tristan Harris and Joe Edelman, talked about “software of regret.” It’s a wonderfully poetic phrase that deserves exploring.
For software developers, the software of regret has some very clear meanings. There’s always software that’s written poorly and incurs too much technical debt that is never paid back. There’s the software you wrote before you knew what you were doing, but never had time to fix; the software that you wrote under an inflexible and unrealistic schedule; and those three lines of code that are an awful hack, but you couldn’t get to work any other way.
That’s not what Tim was talking about, though. The software of regret is software that you use for an hour or two, and then hate yourself for using it. Facebook? Candy Crush? Tumblr? Words with Friends? YouTube? Pick your own; they’re fun for a while, but after a couple of hours, you wonder where the evening went and wish you had done something worthwhile. It’s software that only views us as targets for marketing: as views, eyeballs, and clicks. Can we change the metrics? As Edelman says, rather than designing to maximize clicks and page views, can we design to maximize fulfillment? Could Facebook measure friendships nurtured, rather than products liked?
Computing should enable us to have richer lives; it shouldn’t become life. That’s really what the software of regret is all about: taking over your life and preventing you from engaging with a world that is ultimately a lot richer than a flat, but high-resolution, screen. It’s certainly harder to avoid writing the software of regret than it is to avoid writing spaghetti code that will make your life miserable when the bug reports start rolling in. But probably more important. Do stuff that matters.
Establishing an effective organization for large-scale growth
In the open source and free software movement, we always exalt community, and say the people coding and supporting the software are more valuable than the software itself. Few communities have planned and philosophized as much about community-building as ZeroMQ. In the following posting, Pieter Hintjens quotes from his book ZeroMQ, talking about how he designed the community that works on this messaging library.
There are, it has been said (at least by people reading this sentence out loud), two ways to make really large-scale software. Option One is to throw massive amounts of money and problems at empires of smart people, and hope that what emerges is not yet another career killer. If you’re very lucky and are building on lots of experience, have kept your teams solid, and are not aiming for technical brilliance, and are furthermore incredibly lucky, it works.
But gambling with hundreds of millions of others’ money isn’t for everyone. For the rest of us who want to build large-scale software, there’s Option Two, which is open source, and more specifically, free software. If you’re asking how the choice of software license is relevant to the scale of the software you build, that’s the right question.
The brilliant and visionary Eben Moglen once said, roughly, that a free software license is the contract on which a community builds. When I heard this, about ten years ago, the idea came to me—Can we deliberately grow free software communities?
Learn to be a better programmer by taking charge of your interests
If you want to be a better programmer, a good first step would be to choose an area of software development to take additional responsibility for. Now, when we say “responsibility,” we don’t mean the sort of “you’re to blame and you accept it” responsibility that is so commonly thought of. Instead, we mean the willingness to take charge or the willingness to do something about an area.
So select out some area of software development, and decide to be a bit more responsible for it than one was before. The “area” could be simply some additional part of the current project you work on, the whole project itself, some type of software development that you haven’t done before, some aspect of software development you’d like to know more about, etc. If you’re feeling adventurous, try deciding that you’re personally responsible for the quality of the entire software project you’re working on. If you do, you may be surprised at how much easier this makes your life. When you’re trying to maintain the quality of only a piece of a software project, it’s very difficult. You’re surrounded by complexity or confusion, and you have to fend it off at every turn. But when you look at the project as a whole instead and try to decide what should be done with it as a whole, the solution presents itself much more readily. Now, it may seem like quite a bit more work to resolve the problems of the whole project, and it is. But it’s considerably more satisfying, tremendously more effective, and will bring you up to seniority as a software developer much more quickly than just trying to solve the problems of your one particular area.
"Code Simplicity" author Max Kanat-Alexander on the elegance and utility of simple code.
Simple code is born from planning, discipline and grinding work. But as author Max Kanat-Alexander notes in this interview, the benefits of simple code are worth the considerable effort it requires.
One of the defining characteristics of the Rails movement has been its willingness to throw out the rules by which software developers and consultants have typically worked. Those rules typically produce big, overblown projects laden with features that no one ever uses–but which sounded good during the project specification phase. Build the simplest thing that could possibly work, and…