Tuesday, May 26, 2009

Software Process and Motivation

There are two main factors (besides the obvious lack of free time) that keep me from posting more frequently to my blogs.  The first is a fear of mistakes.  I fear saying something dumb, whether it is just a simple typo or if it is not thinking through my ideas enough before committing them to the Internet.  The second is that it is all for naught because no one reads what I write anyway.  However, if I want readers I have to post regularly, and if I want to get better at writing, I have to keep doing it.  So, for me, a large part of writing posts is a psychological battle with myself.

When writing software, there are also motivation issues that prevent or slow down development.  I think one of the key reasons Agile has such vocal followers is that it addresses the psychology of programming, keeping developers happy and productive.

Fear of Mistakes

While Agile may not explicitly say "Embrace Your Mistakes", the idea of constantly refactoring along with a large suite of automated tests and continuous integration attempts to address this fear.

Useful Software

The other day I was reading a friend's blog (May Contain Blueberries) and he mentioned that he read and enjoyed my blog.  This gave me a huge emotional boost, which encourages me to keep writing.  Similarly, besides all of the tangible benefits to quality that a release early and release often philosophy that Agile has, there is the huge psychological benefit to the development team having people use their software.  Nobody wants to work on something that never sees the light of day.

Staying Productive

Other ideas that Agile methodologies tend to push are Pair Programming and No Overtime.    The No Overtime philosophy is explicitly about programmer morale and mentality and keeping them sharp.   Pair Programming also has this affect.  When pair programming, you are less likely to be distracted by emails about lolcats.  You also have a compatriot who is in the same boat as you, sharing your miseries and successes.

Developers are People

Basically it comes down to the fact that developers are people.  Keeping us happy and motivated is a key component to continually getting quality software over time.   And, while free snacks are a tangible way of accomplishing this (and let me tell you, the Google snack rooms are pretty awesome), process and business practices are more important over the long haul.


As a postscript - it seems that I must feel strongly about this.  I just noticed that I had already posted on Psychology of Extreme Programming.  Oh well.  If its worth saying once, its worth saying twice.  :)  Hopefully I made enough new points to make it worthwhile.

5 comments:

Jeremy Beker said...

Just a random thought about agile programming. I've never actually done it, so I am probably not a good person to comment, but this is the internet and that is what we do here. While I am a little dubious about Agile method (I have never heard of a company that uses it for any sizable project), the one thing that drives me crazy is the people who say that "oh yeh, we do agile except for that whole pair programming and no overtime thing."

Well, you no what guys? Then you aren't doing Agile....

Michael Haddox-Schatz said...

Agile is like many other buzzwords. Lots of people claim to do it (or want to do it), because it is the current fad. But like any other buzzword, claiming you are doing it is very different from actually doing it in ways that are beneficial.

I am also dubious about parts of Agile. Many of my posts here on this blog are me thinking out loud about it.

Viren said...

While I like Agile programming, I've never come across a real-life project where the client has allowed the project to work in an agile fashion. This is true even in the situations where the "client" is internal i.e. for in-house products. No doubt, my experience is biased since it's mostly government-oriented, but most agile methods are also self-selecting in that only certain sections of the software industry are amenable to them, and having it gain acceptance in a lot of segments of the industry is really hard -- and not because people think that such methods are not good.

joshua said...

I haven't clicked here in a while because it hadn't been updated. But hark, here we are. Yay.

I am not a programmer, but I think about that pair programming thing sometime. It seems to me that it divides duties, right? It's easier to think about the big picture when you're not worried about picky syntax rules and typing. So you do that for a while then switch, if I'm not mistaken (?).

When two modes of thought are at odds, like a writer and an editor, then divide them into two people.

I could be totally off da base.

[Saying wrong bullshit is like the requirement of blogging, so just let that one go, man. :)]

Michael Haddox-Schatz said...

Josh, thanks for checking back. I have started posting again, and I have a bunch of ideas, so hopefully this won't die off this time.

Pair programming is a funny thing. And having never really done it, I can only say so much about it. I think you are completely right about one person seeing the big picture while the other sees the trees. Not sure the editor/writer analogy though, as both programmers still have the same goals and skills and are supposed to trade off frequently.

As for Viren's comments about it not often fitting in the "real" world, that is what fascinates me. Can we take the good ideas from the Agile movement and apply them without having to drink the Agile koolaid, and do so in an environment where it isn't acceptable to do it wholesale?