1. Analysis Paralysis is real. Agile development methodologies deal with this at a fundamental level. Yes, it’s not perfect, but waiting too long is even less likely to get it right.
2. Trust is mandatory. Too many approaches seem to maintain an adversarial relationship between the different parties to the project. That’s an incredibly unpleasant way to make a living.
3. Test-Driven Development. Done right, Test-Driven Development captures and stores knowledge in incredibly concentrated form. Far more efficient than boilerplate documentation.
4. Mental Capacity of Users. Programmers, in general, are able to hold complex systems in their head, coordinating and visualizing the whole thing at once, able to understand how the various parts work, how they fit together and how changes in X will affect Y. However, most people do not have this ability, and furthermore, they don’t like to admit that they can’t do it. Unfortunately, these people are your customers and the ones who specify the project.
5. Release Early and Often. Release early and often is the fundamental of software startups. It’s the closest thing I’ve seen to a “Golden Rule”. It’s done this way because getting it in the hands of customers as early as possible is critical to getting good feedback about how the sofware should change. Most projects could do with this level of intensity and desire to please the customers. Not all, but most.
6. Build vs. Buy. The relative shortness of an iteration seems to increase the use of off-the-shelf software, reducing Not-Invented-Here syndrome.
7. Daily Habits. Short, daily meetings (Stand up or sit down, I don’t care) set a tempo for the organization, one that eventually turns into a habit (and in my mind, it’s a very good habit to have - brevity, efficiency and a sense of urgency)
8. User Stories. I find user stories much richer and more illuminating than use cases. Use cases often have more precise facts, and I use them, but I find the stories to be a better way to “get into the customer’s head.”
9. Post-Mortems - I don’t do these as often as I should, at least not formally, but I think they’re very important. And doing one every 4 weeks is very useful to updating the course quickly.
10. Fixed Iteration Deliverables - Again, like item 1 above, it may not be perfect to hold the deliverables constant for 4 weeks, but it works a lot better than the alternative in most cases.

You might be able to come up with another approach to software development that avoids these, but Agile development seems to embrace them all quite well.

I’m still a skeptic on a few things:

• Pair Programming - not against it, just not convinced, and not interested in trying to fight for it.  It seems like a wash to me.
• Integrated Customer - seems infeasible, and with a decent team, unnecessary.
• Growing the Architecture - I’m actually ok with this to some degree, except in communications between systems - in my experiences writing and implementing communications protocols, they need to be thought through more than other parts of the system, because they aren’t as malleable as the software itself.

(See the whole list here)

Those That Blog

Some programmers are bloggers - they write articles, post things they’ve learned, rain hate-filled bile down upon those they dislike.
Bad Things

• Anyone who considers their opinion to be solid and well-informed enough to justify sharing it with the world is fairly arrogant
• They are more likely to be Prima Donnas
• They can sometimes be nasty and difficult to argue with
• They will often post negative stories about their work experiences
• They will sometimes miss deadlines because they are too busy blogging

Good Things

• They are often well-informed about the state of programming, because blog writers are also blog readers
• You can get a sense of how competent they are just by reading their blog - if they write poorly, or always seem hateful, it’s a good sign that you don’t want to hire them
• Many of them are better than average with American English - spelling, vocabulary and sentence structure.
• Some of them are exceptionally witty, polite, intelligent and unusually modest. Oh and handsome, yes, handsome too, even if all those girls laughed at me in high school… well, I showed them, didn’t I!? Hah. Thought they were too good for me… But they’ll get theirs.. oh yes… oh yes…

Sorry, where was? Oh, yes, Programmers that Blog

How To Identify Them

• They include their blog address on their resume
• They mention in personal interactions that they blog
• They say “I should blog about this.” when you tell them something interesting
• When asked about their hobbies they say “Oh, and I write a blog.”
• Instead of a lizard, they have their blog URL emblazoned on their shirts
• They will wander around aimlessly, saying “blog, blog, blog.”
• They mention things like “Technorati” and “Reddit” in casual conversation

It reaffirms my opinion that you can’t really communicate with some people by just talking to them.

Some people need much more interactive, “multi-media” encounters to fully comprehend their interlocutors.

Also, some people are just really, really dumb and/or full of themselves.  Alas