anthonylauder

Anthony Lauder

Developing Software in the Real World

Commercial Software Development

My name is Anthony Lauder (about me). I have been involved in commercial software development for more than twenty years - with several years at University studying computer science (including a PhD), and several earlier years as a spotty teenage computer nerd.

Those Idiots Over There

Project successes are easy to credit to ourselves ("Without my great contributions, this project wouldn't have been anywhere near as successful!"), and project failures are easy to blame on others ("How could it possibly proceed with those idiots involved?").

Finger Pointing

I have been pretty guilty of finger pointing myself. Of course, when you point one finger at somebody else, your hand is pointing three fingers right back at you. Most projects don't have clusters of fools that just don't get it. Rather, different people have very different beliefs about the best way to go about a project. Other people probably think you are as foolish as you think they are. No amount of intellectual debate is going to turn them over to your way of thinking.

Book

I am writing a book. I started writing a a different book but along the way it became clear there was a book missing. Plenty of folks said to me things like "sure, this Agile stuff sounds good on paper, but it doesn't work in practice". Plenty of other folks say similar things about all other approaches to software development. Just as with project blame (see above), no amount of intellectual debate is going to turn them over to your way of thinking. Why is this?

Software Project Cultures

I have long felt that people have emotional responses to methodologies: they reject or accept any given methodology based on gut instincts. It seems to me that these instincts come from metaphors underlying three very different software project cultures. The book I am writing explores those cultures and metaphors in detail, so you can grasp the mindsets of people committed to them. This will help you to unravel your own attitudes to software development, and also those of others. When you speak to people about projects, and how to run them, or you read somebody's specific methodology, you will no longer have to rely on a instinctive reaction. Instead, you be able to feel and understand where they are coming from, and with that be better positioned to work with them, rather than stand your ground in conflict against them. You may even be able to upgrade a culture to a more effective one, without it inevitably twanging back to where it started from.