+972 52-548-6969
Don't make me THINK!
I am having a good discussion in the ALT.NET mailing list about how to get buy in from developers for advance concepts. From my point of view, this is based solely on making it easy, transparent and simple.
If you can set up a system that means that the zero friction path is also the path for good design, you are golden.
In other words,
A while ago I was asked what I think was a good quality for an architect. My reply was that he should set things up in such a way where the developers are bored.
That may sound... harsh to some, but I believe that we have enough complexity in our applications as it is. A success story is reducing the complexity to such a level that we focus on the business value, rather on the technical difficulties.
Good tools help, but only to a point, the environment should be setup in such a way that the easiest thing to do would be the right thing. That takes some work, I'll admit. But once it is set all the way up... you are golden.
I have this experience in my last three projects, where the environment was setup in such a way that taking advantage of IoC, AOP and ORM was simply the natural thing to do. All three projects have to deal with a fair amount of complexity, some of it technical and some business requirements. We rarely need to deal with the technical issues, they are buried and out of the way. (Well, I tell a lie, we built some on MS CRM, which means that the foundation is made of tissue paper and keeps crumbling under us. Don't use MS CRM, for anything other than an example how not to build software.)
This means that we can spend all the time actually producing business value. It also means that I have a lot of junior people on my team that can immediately make use of very advance concepts and produce good, solid software.
Comments
"the environment was setup in such a way that taking advantage of IoC, AOP and ORM was simply the natural thing to do"
That's just begging for an article of it's own!
[)amien
Excellent observation, this also in my opinion one of the biggest reasons to put coding standards in place. It's amazing when I look back and think how much time I saw wasted because developers couldn't aggree where in a Source Control system their project should go.
On a side note, can you expand on your feelings on CRM? I just narrowly escaped having to produce an application that would extend CRM, and am curious why you feel as strongly as you do.
-Josh
Josh,
Check this blog for past posts about it.
If you're talking about abstracting away the trappings that facilitate doing IoC, AOP, or ORM from the "average" developer, then I agree. i.e. a junior-to-mid developer doesn't need to know the ins-and-outs of NHibernate to use ORM on the project...
hey, only one josh allowed here and I was here first. /kidding.
-j
(notice the different signature ;)
But you've GOT to spend some time explaining the principles behind these concepts, right? Is the "easy environment" enough? When you teach your teams how to build maintainable apps, do they also see the "why"?
I fully understand lowering the barrier for entry, but does your team understand why ORM is good? This reminds me of the discussion that Dave Laribee and Scott Hanselman had at altnetconf. They talked about creating leaders instead of more followers. Leaders created geometric knowledge growth, while collecting followers limited you to linear growth.
I think you've touched on the essence of being a good software architect - create an environment in which it is easy for developers to succeed in creating good software. You cannot legislate good practices, because programmers are a stubborn bunch. You have to give them a "lazy" path whereby the easiest, most obvious thing is also (architecturally) the best.
One team member who recently left us told me "I am dreading interviews, because I have been doing .NET development for 2 years, but I will not be able to answer questions about ADO.NET". I took this as both a compliment (because he was able to achieve so much with so little knowledge), and a warning that I should try harder to involve the team in the designing and coding the inner workings of the application.
@Jimmy, I didn't get the Ayenda was saying the concepts shouldn't be understood, just how they got to be able to property implement the concepts is abstracted (i.e. they know and are implementing IoC , but they may not know it's Castle doing it...).
Comment preview