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.

Microsoft's ASP.NET MVC Framework

I attended the Alt.Net conference in Austin a few weeks ago. One of the highlights of the weekend was seeing Microsoft announce and demo the MVC framework. Scott Hanselman has the full video recording here.

I have to admit that I wasn't that interested at first. I've done MVC in Struts. I've seen MVC in action in Ruby on Rails. There is already MonoRail in .NET that allows me to do MVC. So a MVC framework in .NET didn't really represent anything new to me. I figured Microsoft's version would be so convoluted that it would be more pain than pleasure.

I have to give credit to Scott Guthrie and his team. They definitely did their research into other MVC frameworks both .NET and in other languages.

Some highlights:

• Unit testing
• Provides hooks for extensibility
• Routing
• Convention over configuration

I was happy to see that I could unit test controllers without the need of a web container. Yes, Microsoft has written a framework with testability in mind. I was so happy to see Microsoft thinking about testability in an application, and I'm not required to use MSTest!

The framework is highly extensible. Everything conforms to an Interface. It comes with base implementations of the interfaces, but this allows teams to use their own implementation. That means teams will be able to use their prefered IoC container to create controllers. Or use monorail as the view engine if you'd like. Scott even showed an implementation of an attribute-based interface that cached responses from a controller. Open, Interface-based frameworks is something I was used to in the Java world, but hasn't always been the norm in the .NET world without putting stuff into the GAC or jumping through hoops.

Routing pretty much looks like you would do it in Ruby on Rails.
/Controller/Action/Id

As a result, building RESTful applications in the .NET MVC framework is pretty simple. I did ask one question about Routing during the presentation. Did I have to go through the pains of configuring the mapping of every single controller? This was something that really annoyed me in Struts - large configuration files with every single Action class mapping. Microsoft definitely went the way of Ruby on Rails's routes.rb.

I was pleased to get the answer I wanted to hear. The framework's base routing mechanism (again, you can plug your own in) takes convention over configuration. If you have the following:

/UserController

The routing service will look for a UserController class, and use the Index method by default. All that is needed is to tell the framework which namespace/dll the controller classes are in. The idea of convention over configuration is a powerful one. One which has lead many to Ruby of Rails, and will definitely be a plus for those adopting the Microsoft MVC framework.

I can't wait to get a CTP or Beta release of the MVC framework. Goodbye code-behind!