Bart Waeterschoot is blogging on IntoFactories.NET. I'm glad he joined the blogosphere. Bart is a very smart guy and I'm looking forward to more of his writing.
Nonetheless, I have to respectfully disagree with some of the content of his last post Read Software Factories - The developer gap.
He starts his case with the fact that
The gap between ‘regular’ developers and ‘extreme’ developers is widening very fast.
This one I do agree with. Its why we need coaching skills so badly. This is one of the things that ALT.NET is all about: showing other developers in the .NET space that there is more out there than just Microsoft. Drinking the kool-aid that the ALT.NET masters are or should be laying out for us.
Bart goes on talking about automating best practices. Then he states:
And best of all, you can choose to just use the factory without knowing into detail which technologies and patterns lie underneath.
This seems very dangerous to me. Let me share some wisdom from Keith Pleas:
Protecting developers from the consequences of bad coding encourages bad coding.
And he's right you know. I'm going to make a statement here:
If you don't know the patterns underneath a certain framework or tool, then please, don't use it!
Let it be NHibernate, CAB, whatever, if you don't know what's going on under the hood, you're setting yourself up for failure. If you don't understand the problems its solving or how it does it, you are heading for disaster.
If you have someone on your team that is famous for writing the most crappy code on the planet, they will keep screwing things up. No matter how much effort you make into preventing someone messing it up: they will always find a way. Can you blame them? No. Why? Because they don't know any better. If you explain why they are doing things wrong, they can learn. If they still find resistance, then you have other problems to worry about.
You don’t need a full-blown software factory to start bridging the gap. Just start gathering all internal best practices in your company and bundle them in a document, write code snippets, save project templates, ...
You're 200% right on this one. Our team is having a meeting every month with one goal in mind: Share the intellectual wealth. We exchange information about things we find useful and about the things we don't find useful. It's like our own private ALT.NET open space conference. We keep track of these practices in a document. These are our guidelines. This is what we as a team want to do in order to constantly improve ourselves, to make progress in what we do as a team. The first thing a new team member does, is going through this document so that he can contribute as fast a possible.
The essential point I'm trying to bring here, is that I don't believe software factories as a methodology is a good thing. I'm a big believer of self organizing teams (must read!!). Everyone in the team is responsible. As a developer your responsible for the design, maintainability and stability of the system you are trying to build. I agree that there are different types of developers out there, which is a good thing. Embrace the diversity of your team, and start utilizing the different talents that you have on board.
Trying to protect developers against their own actions shows that you are failing as a team and that you have trust issues. I recently sat down in a meeting with someone of the central architecture team (yes, this ancient phenomenon still exists). He mentioned somewhere during this meeting that we couldn't do option X because the developers of the applications using it could not be trusted! How about communicating things and explain why doing this particular thing for option X is actually bad? Maybe, these developers come up with another solution that is even better.
I'll definitely like the pragmatic approach Bart is suggesting with code snippets, project templates, etc. ... . I do believe that they are of use on a micro-level.
Let me know what you think. No silver bullets, no universal truths.
