"Typical" Software Development

Everyone working in software development has heard it at one point or another. The conversation usually goes like this:

You: “We don’t need X, that’s what Y is for”

Them: “Well, generally the way it works is that X is used for a while, and THEN Y is used. But if we need to what you said to move on, then that’s fine i guess.”

Or

You: “You know, we usually format our user stories like this”

Them: “Well typically user stories are this, but I’m still trying to figure out what you think they are.”

It’s frustrating to hear. Some people know how to do things and want to continue to do them their way because, frankly, that’s all they know. They think any divergence from what they know somehow makes what they’ve done in the past “wrong”. However, what they fail to understand is that there is no “typical” way to do software development. Every situation, every client and every project is different. They have different constraints, different egos and different expectations.

I’ve always thought that understanding the above is the difference between a ‘senior’ team member and a ‘junior’ one. Unfortunately, it seems like people have started to use years of experience as a measuring stick as opposed to maturity of their skills and traits. That’s a shame, because with lofty titles, people often become even more resistant to change and learning new things.