The Agile Architect
Does Experience Inhibit Agility?
Knowledge and experience have an expiration date, especially in the IT world. As our Agile Architect hits 50, he ruminates on the idea that more experience doesn't necessarily equate to better results.
I had a conversation this morning with a younger, less-experienced colleague that struck a chord in me. I had gone to her for advice on an important initiative that she is leading for our company and that I am supporting in a minor way. What struck me was that she was genuinely surprised that I was seeking out her advice.
And that started me thinking. Why was she surprised? I suppose she thought that with all of my experience, she wouldn't have anything valuable to offer. Or perhaps she had the expectation of me that I wouldn't think she had anything valuable to offer. And, for that matter, why did I? I have at least a couple of decades more experience.
With those thoughts jumbling in my head, I went back to work on my current project, which involves scaling a classic ASP application to support 100 times more users than the current version. In order to be able to horizontally scale the system, we were going to have to change session management from an in-memory model to something that could be shared across an IIS server farm and/or server garden.
My youthful pair and I were discussing options for sharing the session. I wanted a solution that would be interoperable with ASP.NET so that in the future we could add functionality using modern technology and remain interoperable. And I almost had him convinced. Until he brought up that modern .NET best practices use RESTful APIs that are stateless. We shouldn't spend time on session interoperability because there shouldn't be a session.
And that's when that little niggling of a thought in the back of my head solidified, that experience doesn't necessarily lead to the best results. In fact, it can be downright misleading.
The Agile Architect Hits 50
This is my 50th Agile Architect column. Coincidentally, I just had my 50th birthday. And the questions in my mind are "Have I aged to the point of irrelevancy?" and for that matter, "Are my previous columns still valuable and valid?"
With that in mind, I've got some advice for the old-timers out there like me on how to stay relevant and a few words of wisdom for the newcomers on how to deal with us old geezers.
I'm an Old-Timer. What Do I Do?
Work with younger team members. They aren't filled with the same preconceptions you are. When they say something that sounds crazy, listen to them, accept it, time box a spike and see how crazy it really is. Don't be too quick to shut them down with a hundred reasons why it won't work.
Be willing to give up on "best practices." Today's best practices are tomorrow's "Oh my God, I can't believe we used to do that."
Recognize that the problems that drove well-established practices may no longer exist. Here's a non-technical example. Cursive was invented to prevent the ink from your pen from smudging when you lifted it from the paper. It's not being taught in the schools and kids today can't read or write in cursive. Now, if you are over 40, you are saying to yourself, "My God! How can they not know cursive." And if you are under 25, you are thinking to yourself, "What's cursive?" I would go further and say that the Swype keyboard is the new cursive.
Watch how people from different generations interact with technology. Software that you create for 20-somethings is going to be different than software targeted to baby boomers.
I'm Young and Eager. What Do I Do?
First of all, do listen to us old geezers. We sometimes know what we are talking about.
On the other hand, don't slavishly follow the elder statesmen on your team. Question what is being done and why. If you can't make your point, don't argue fruitlessly. That frustrates everyone. Instead, ask for some time to spike out your solution to prove your point.
Recognize that the different generations think and act in different ways. No, we aren't all the same but there are generational themes based on shared experiences.
Final Thoughts
As to the question of the relevancy of my old columns, I guess you'll have to read them and judge for yourself. But enough ruminations about age! On an agile team, everyone contributes. We shouldn't judge ideas or people based on age or experience. A healthy mix across the spectrum creates a well-balanced team. And as long as we are working together, learning together, getting better at the craft of agile software development together, and delivering value to our customers together, nothing else matters.