Human Software Development
From xoa
Contents |
[edit] Overarching principles
For both (human software) development, and human (software development).
As Yaakov says, "Humans first, code later".
Software development is an inherently human undertaking. Helping humans, working with humans, treating them as humans, only helps all development.
Is your proposed coding solving a real problem or serving a real need? Do the humans have a clear understanding of the problem and its solution?
All humans are inherently worthy of respect.
Developers forget the human cost of development at their own peril. Why do you think DeMarco & Lister's Peopleware is such a classic?
[edit] Social items
In the world of programmers there are two damaging assumptions. First that our social realm operates as a meritocracy. Second, that a meritocracy is actually the best possible way for it to operate.
The first assumption is only partially true. Merit, in the form of IQ and effort, do tend to drive social standing. But, on the other hand, aggressiveness, backed up with this putative "merit" is the source of "power" over others in the community. That is to say, those who are willing to ignore the humanity of others in the community, and have the *luck* of IQ and are wiling to work at it, don't have to be the best among us--not even the best programmers--to co-opt the community infrastructure, generally for the sake of their own satisfaction.
The second assumption is based on the idea that the ultimate goal is to have *individuals* who write clever, efficient programs. If the goal is redefined to put people (humans) first, the suitability of a meritocracy with the narrow definition (per Michael Young) of IQ plus effort becomes starkly incompatible.
I believe the root is, as I say, an unquestioned assumption that a classical meritocracy is "the right thing" because the unquestioned focus is on the *code* first, then the humans. The IQ + Effort formula needs revision, based on the idea that some of us are sick of the human aspect of community being given short shrift. There is no logical argument to be made for altruism in the programming community. If you don't understand why it is important, you won't find a reason to join us. In fact, you will see our efforts as "stupid". Alternatively, if you find that the idea of shifting focus to programs in service to people, not people in service to programs makes sense to you, please do join us and help us.
The problem that HSD seeks to address is a core issue for the process of creating software. First, the process of development needs to be humanized. Human qualities beyond knowing every detail of a particular language or dozens of classic algorithms must be valued and fostered. Then the software itself, the work of the community must always be seen as a service to people. Human interface design, for example, requires understanding how people think and work, knowledge that involves interpersonal skills often weak in "programmers". An ideal interface is one that makes the computer do the work of the person, not the other way around. Further, aesthetics make the experience of using software needed to do your job more pleasurable; it is another way software can be in service to people. Why is it often said as if with pride "we are programmers, we don't know how to make things beautiful"? We need aesthetically skilled people who may be only mediocre programmers as much as we need aesthetic dolts who can write complex algorithms. Each must value the other for what they contribute, neither must be seen as "better" or the "real" programmers.
In all work, we should seek to incorporate the full range of human expression so far as it is possible. In creating software the focus on the success of the unseen and seen should be equally emphasized. The applications should be easy to use to the point of transparency for the user. The should be beautiful to look at and even fun if possible. They should, of course, also be internally ordered for efficiency, maintenance and optimal function. All these things are important. It is ironic, I think to note that from the user's point of view it is *only* the ease of use and aesthetics that matter. As long as the program "works", it is good. We are aware, as programmers, of the possibilities of internal beauty as well. This shouldn't make us believe, though, that our view is superior. There is a legitimate value to the view of the user of the software, who, after all is the reason we are writing it in the first place.
[edit] Technical items
Shared code & Constant code review
Focus on code, not coders
Poison people can be identified by finding the slowest team
Google social apps API
Open source & the inherent social aspect
[edit] Initial invites
- Andy Armstrong
- Jim Brandt
- Julian Cash
- chromatic
- Ben Collins-Sussman
- Liz Cortell
- Jason Crome
- Richard Dice
- Brad Fitzpatrick
- Brian Fitzpatrick
- Adam Kennedy
- Pete Krawczyk
- Andy Lester
- Bill Odom
- Curtis Poe
- Allison Randal
- Kirrily Robert
- Yaakov Sloman
