The Configurable AntiPattern

I was reading through an RFP a few weeks ago, and one of the requirements that was listed in the RFP was "make it dynamically configurable."

Why did this requirement seem so familiar?

I've seen this requirement before, but disguised differently. It's that dynamic administrative feature like being able to build ad-hoc reports from any data in the database without knowing anything about the relationships or SQL. It's that feature that never makes it into the product because it's just way too costly and time-consuming to build. In the end, we always end up building a few canned reports.

I spent some time asking myself why does this dynamically, configurable requirement always pops up? The RFP writer had good intentions. If the developers just build something that is configurable to the n-th degree then it must meet the user's needs. Dynamically, configurable. It's the catch-all term to make sure every possible scenario for tomorrow is taken care of today.

I believe that this (nearly) impossible feature makes its way into most projects because someone didn't spend the time and effort to fully understand the real needs of the users. Instead of spending a little effort with the users to identify what they really need in order to do their jobs, it's just easier to ask for the dynamically, configurable thingy.

I think this has similarities to Chris Stevenson's The Editable Grid Pattern.

A quick measurement of your organization's technical skills

If your organization's senior developers write static methods for everything, then you might want to question the capability and desire of your technology leaders to learn, grow, improve and expand their understanding of their chosen profession.

How will an organization's developers be able to quickly and effectively utilize newer technologies and ideas when they haven't grasped something like Object-oriented programming in the over 10+ years that it's been in the mainstream?

Technical Lead role

"I made the typical blunder that many first-time technical leads do. I put the headphones on and hunkered down with what I thought were the most difficult pieces of code and did them. I gave the other developers what I thought were easier tasks and generally ignored them as much as I could."

I read Jeremy Miller's blog entry, Classic Technical Lead Blunders the other day which got me thinking about the Technical Lead role. I've been the technical lead on a half-dozen or so projects. Some 4-5 people, others with 15-20. I too made many mistakes the first few times around. I'm sure I still do make mistakes today.

One of the best pieces of advice I've received was from a colleague, John Kordyback. He told me that I had to learn to delegate. In many ways, that is very similar to the quote taken from Jeremy's blog. I was doing a pretty good job leading a team of 4-5 people, but as the projects got bigger, and the number of people got larger, I had to learn to delegate to others. I could not take on all the difficult things myself. I had to learn to trust others. I learned to let others stretch themselves.

So, if a Technical Lead is constantly delegating, what exactly should a Technical Lead be doing? Surf the internet in a cozy office/cubicle? I've realized that a Technical Lead is much like a Project Manager. One of your duties is to remove (technical) barriers. An effective technical lead will be able to recognize barriers, and figure out how to remove them. That doesn't always mean that you should be the one fixing them. Solicit advise/solutions from the team. Make them think about the problems too.

An effective technical lead is never happy with the status-quo, and is constantly looking for ways to increase the team's velocity. Some would equate this to the Lean Software Engineering phrase, "eliminate the muda." "Muda" roughly translates from Japanesse to English as "waste."

Another idea that comes from Lean Thinking is a Value Stream Map. As a Technical Lead you should always have a mental picture of your delivery value stream map. You should understand where the waste is. Your role is to eliminate muda. From a technical standpoint, this could be many things. Some examples of muda that I've seen over and over on projects:

• Tests take 45+ minutes to run. Thus, developers are wasting hours in the day simply waiting for tests to run.
  
• Unbeknownst to the developers, the DBA applies a change to the development database. All of the developers stop writing code, and instead are trying to figure out why the application has stopped working.
  
• The deployment process to the test environment takes a developer away from the project for half the day.
  
• Merging a feature back into the code takes more time than actually implementing the feature.
  
• The time to write the unit tests take exponentially longer than implementing the feature.
  

All of these lead to massive waste on a project. As a Technical Lead, it's your responsibility to recognize these types of issues that negatively effect the project's velocity. Find solutions. Weigh the time it takes to implement changes against the waste it will remove. With the help and support of the team, apply the changes. Continue to re-evaluate your Value Stream Mapping, and implement new improvements.