Software Development
Blogs and Discussion
developer.*
Books Articles Blogs Subscribe d.* Gear About Home

Individuals Over Processes is the Key

[I wrote this blurb nearly a year ago, and I'm using it as my first post here at developer.*]

Victor Skowronski, an engineer with Northrop Grumman, wrote an article "Do Agile Methods Marginalize Problem Solvers?"(IEEE Computer, Oct 2004). He argues that bright minded problem solvers would not work well on an Agile software project. Isaac Newton and Thomas Aquinas are provided as historical examples of bright minded thinkers, and surely they were. But he defines "the best programmers" as "having the most advanced problem-solving skills"; then in the next several sections of the article states that this may involve extensive personal research, time to mull things over, and an incapability to convince others that the solutions found are "the right thing to do". Yes, the private / shy / introverted personality does sometimes accompany the creative person. But I would not want my team of software developers to be composed of only these "best programmers". We would never get our products to market and would soon be out of business. This person can be an asset to the software team - but only a particular aspect of it; the team of best programmers should be primarily composed of those who can work closely with others.

What we can take home from Skowronski's article is not that we should ditch Agile methods, but that we need to use a method that adapts well the the needs of each developer. If the method cannot be adapted this way, then it violates some of the basic tenets of Agile methods:

The first value listed in the Manifesto for Agile Software Development is "individuals and interactions over processes and tools".

Three of the Principles behind the Agile Manifesto are related to the personality of the developer:

  • Business people and developers must work together daily throughout the project.
  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Business is first of all about people: the people who work for the business and then those who receive the product or service. Individuals over processes is the key. Take care of your people. Help them to do the best work they can do.

[I corresponded with V. Skowronski about his IEEE Computer article. In a future post I will provide some of his comments as well as further elaboration on people and work.]

Thanks

The problem is that many more people (like me, f'rinstance) think they are Newton or Aquinas but may not be or are not (as in forget about it).

Knowing software doth not a Newton make because software at best is the Bobby Fischer like mastery of an artifact, and not the understanding of Nature as in Newton or God as in Aquinas.

Personally, I had to unlearn the very idea that I "deserved" as an Ace Programmer to bother everybody with my smoking, my swearing at my computer, or my rewriting other people's code just because I thought I was some sort of Genius, years ago.

To this end, I took three Outward Bound classes to learn teamwork and leadership and I realize that the minimum wage Outward Bound instructors had mathematically more skills than me.

At the same time, this very training made me impatient with the reified world of development and a rebel again in a different register.

Where is the idea that it might be a Good Thing for an Isaac Newton to sit down in pairwise programming with Joe Schmoe?

For does not Confucius say that "when the wind blows, the grass bows down before it?", meaning that our ingrained data-processing idea (that the common folk will necessarily reject a computing Newton and find his code unmaintainable) needs re-examination.

I realize that it is a well worn saw in data processing shops that what Confucius would call the computing shih or gentleman has no place, and that he would confuse the rabble, and of necessity write, if with beautiful calligraphy as does the *shih*, unmaintainable code.

That somehow, one needs to succeed, to rise above, while retaining the common touch, like Jack Welch or Don Trump.

Consider that this may be an urban legend injected over time in data processing culture by a management whose postwar legitimacy, as described by John Kenneth Galbraith in The Economics of Innocent Fraud, is necessarily (innocently, in a sense) manufactured by there being no countervailing sources of authority, whether from labor unions or programmers who know "more" about the accounting systems than the CEO.

Of course, it is a self-fulfilling prophecy if knowledge includes authority (the ceremonial right to speak with authority). The Chiefest of the Chief Programmers of all the tribes may literally not know that he knows enough to be dangerous.

However, this operates at the level of what Barthes calles the mythos. In the real world, real programmers continue to acknowledge authority based on knowledge.

In the real world, it might do The Angelic Doctor or Newton a world of good to be a Teacher.

Furthermore: the very idea that you even need a Newton to design a data system would be completely true only in a truly just society.

One more comment. If you as a developer can't stand the idea of working closely with "business people" another single day, if you've had it up to HEAR with their lack of imagination or even morals, it's time to visit the not for profit as well as the techie zones of Craig's list.

Note that in American computing literature, we always do this: we always use "business rules" to mean "business rules, and oh yes, government, universities and not for profits. Them too, for sure, you betcha."

This limits our vision. The fact is that you have the choice to become a programmer, developing systems in the Gaza Strip for UNHCR and other organizations while sharing space in one of the most crowded places on earth and dodging Israeli missiles.

Hey, I just helped a friend here with his PhD thesis about the Barefoot Engineers of India who install solar power and who all make the same small amount of money. I bet they need Barefoot Programmers, but at the same time, their "rules" ain't "business rules".

Indeed, I show in my book Build Your Own that being able to write parsers can make you more conscious of the thing-hood, the reified quality, of the "business" rules...to the extent that you don't have to encapsulate deep assumptions. I provide a specific example of credit granting flexibility where we want to give poor borrowers a LOWER rate.

Of course, this can be hard-coded but with overall more difficulty and less flexibility.

The phenomenon of the frustrated Aquinas may have in other words a hidden ethical dimension. Maybe that "brilliant" programmer is so "brilliant" because, years ago, with 800 on his math SATs, he was accepted into Princeton and wanted to become a theoretical physicist working on nuclear non-proliferation.

But maybe along the way life threw him a curveball and now he works on Wall Street to support his family, while retaining ethical views under his technical brilliance that question the whole meaning of financial data processing (which, economist Jeffery Tobin has shown, contributes to world poverty).

In other words, our boy is a brilliant coder not because of some unexplained knack or talent (mere words that are expressive of the bourgeois incomprehension of the possibility of exit from exchange relations) but because like Newton (who was in later life a mystic) or Aquinas, our boy, unlike the average killer ape in the behavioral sink of the American city, think that truth is, well, true...that bugs can be fixed.

OK, he doesn't want to sit next to some stinker in Pairwise development but this is more a comment on the fact that our boy is not yet fully enlightened, for a fully enlightened man would either sit down next to Joe Schmoe and get to work, or else walk out the door.

Few more thoughts

The IEEE review may be theoretically narrow, jos.trem.

That is, research on software productivity in America accepts as givens social arrangements that a genuine critical sociology might question.

The "given" here is the common idea in computing that there is a sharp distinction between the "brilliant programmer" who prefers to work alone and has at times difficulty in selling his ideas, as opposed to an "ordinary Joe" who prefers to work in a group and replaces "creativity" with hard work.

The theoretic aspect not considered is that BOTH personalities and the imagined divide between them are manufactured by social conditions.

Marxists of the idealistic as opposed to thug variety, both famously and infamously, thought that the proletariat once freed from toil by automation and justice would grow to a single post-revolutionary personality which has been described as the Marxist's own projection.

This would be the "cultured" New Man who would on the job be allowed under worker self management to be just as "creative" and as much of a truly free agent as the boss or his mates, while at the same time willing to subordinate his "ego" to the demands of the group.

Whereas the Marxist (whose ideas remain ideas that have to be confronted despite their tragic results: free market ideation has ALSO produced tragic results such as the Irish famine of the 1940s) would dismiss out of hand the computing split between the non-alienated but frustrated "genius" and the alienated but hard working grunts.

He'd describe the former as a bourgeois fantasy, that technology can even be produced by individual geniuses. He'd recall to our embarassment the story of Nicholas Tesla versus that of Edison, where the less imaginative Edison was nonetheless skilled in organizing teamwork.

He'd point out that in computer programming, the very idea of "individual creativity" is a mythos in Barthes' sense since in being oh, so very "creative" we have to presume a vast supply chain.

This supply chain extends both in space and in time. In space, we depend on elaborate operating systems and hardware as well (trivially but strangely crucially) on alternating current coming out of the wall.

In time, we "stand on the shoulders of giants" because any more than micros were invented at Intel in 1972 (but represent a reengineering of old and simple mainframes on new chips), the mainframe itself evolved from IBM "tab" equipment and a large variety of devices, described by Norbert Wiener as "cybernetic" in his 1940s writings and including technology as disparate as telephone switches and shipboard controls.

The Marxist would thus conclude that the "Leonardo da Vinci programmer" is sort of kidding himself about his "genius" and should be sent out to the country to work for and learn from the peasants.

[Just kidding (sort of in view of my experiences in Outward Bound) about this last. Jung Chang, in her book on growing up in Mao's China Wild Swans, describes the reality of thug Marxism and also the way in which the peasants could not either use the labor of, or teach, the intellectuals sent their way.]

But our stage Marxist would also be hard on the "grunt" programmer who replaces flashes of brilliance by hard work, for he'd note that this type of programmer is "alienated" in the sense that he doesn't have the "genius'" tendency to take ownership of his work or of problems in his work.

The "grunt's" work remains overall of lower "social" value (whatever that is) because the grunt, for his sanity, cannot invest too much of his personality in the work.

To the Marxist, it is actually better to replace these splits in personality types with a single redeemed human type.

Now, given Marxism's track record, this view should probably rejected but for one feature of programming work.

This is that the best software engineering books like those of Gerry Weinberg are actually calls for a single way ("egoless" in Weinberg) of approaching work and by the very fact of their being normative sets of "ideas" for doing work in the first place, they have to favor a less alienated type of programmer over another, one which through personal growth is capable of a generalized genius.

The libertarian mythos of the digerati is that we all are, or should be, "free" to do things Our Way. This is a "real contradiction" to the fact that we're not working as programmers on Fun Stuff.

We're working on things which control, structure and in significant ways damage people's lives and our final contraptions are neither Newton's Principia Mathematica nor the Summa Theologica Contra Gentiles nor the Mass in B Minor.

Indeed, thinking of a large credit-reporting system, which in significant cases drives people to suicide in cases of identity theft or dunning, in the same category as the output of a Newton or a St. Thomas Aquinas is in the worst sense "writing poetry after the Holocaust", to use a telling, a questioning phrase of Adorno.

That's because Adorno took very seriously the idea that History might have a telos and a direction, in the downward direction, where energies that might write a B Minor Mass instead are directed (in the Communist case, equivalent for Adorno in many ways to the free market case) to digging a White Sea Canal or writing a credit reporting system.

The hell with Adorno. There is still work to be done, of course, and doing it as best we can is a moral choice.

But in the years since the Psychology of Computer Programming, instead of converging on a single Tao or Way, programming has in fact continued to split into warring tribes and world views.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Recent comments

User login

About our advertising.

Atom Feed

developer.* Blogs also has an Atom feed, located at this url.

Click here for more information about Atom.

A Jolt Award Finalist
Software Creativity 2.0
Foreword by Tom DeMarco

Recent Posters

Based on most recent 60 days, sorted by # of posts and name.

Google
Web developer.*

Who's online

There are currently 0 users and 43 guests online.

Syndicate

Syndicate content
All views expressed by authors, bloggers, and commentors are their own and do not necessarily reflect the views of developer.* or its proprietors.
Click to read the Copyright Notice.

All content copyright ©2000-2005 by the individual specified authors (and where not specified, copyright by Read Media, LLC). Reprint or redistribute only with written permission from the author and/or developer.*.

www.developerdotstar.com