(Sorry for the recent codeless posts, but these are just some of the things I've been thinking about and dealing with recently)

As I continue down this road as a software consultant (still with a consulting firm), I find myself working more and more with other consultants who are considered "senior", which for some reason includes myself.  I'm starting to see that this can be one of the biggest roadblocks to change and one of the biggest producers of fear on a team.  At least speaking for myself. 

"We're 'Senior', We Don't Need No Stinkin' Code Reviews"

This is the kind of mentality that, though common, is pretty unfortunate.  We all know code reviews have been abused over the years, but does that really mean there is no benefit in "having a 2nd pair of eyes", as they say?  Isn't this still a powerful way to learn and grow a team's skills? 

But this post is not about specific practices like code reviews.  The greater point I'm trying to make is this:  Is it possible for us all to put down our "senior" statuses and strive for perfection as a group of passionate developers without the fear of offending each other?  I'm not sure this is completely achievable as long as we're all allowed to have opinions, but it certainly sounds like a nice goal. 

Even though perfection is unachievable, I want to get as close to it as I can.  Both, in my walk with the Lord and in my craft as a software developer. 

One of the main benefits I see to all this ALT.NET stuff is that when a group of developers (notice I didn't say "senior developers") can get together and critique each other's ideas in a constructive way that actually leads to overall improvement and learning, then I'd say that's a huge leap in the right direction.

"Now Let's Not Get Crazy And Actually Try To Improve Our Code"

Fear quenches the ability to improve.  If Joe Developer is afraid to make a suggestion to another developer or his team because he's afraid of either a) someone getting offended and/or b) someone biting his head off, then chances are that the team's overall skills are pretty stagnant and their ability to improve is severely limited.  Fear can also come from working with unwieldy code bases.  When everyone on the team is afraid to change anything because they don't want to break something, then you've got some serious changes to implement.  I'm starting to go through this process now on a couple of my current projects.  One baby step at a time.

"We're Too Busy To Learn Fundamental OO Principles And Practices"

Well, like a good friend of mine told me recently, "you're gonna pay for it somewhere".  Either through lots of pain in the ongoing maintenance of poorly designed software or in the investment into your team to learn/teach better ways of building software in the first place.

Now that I've pretty much "settled in" to my new consulting firm, I'm going to really start spreading the knowledge that I have (what little that is) to try and build up the teams I work with as much as I can and perhaps encourage others to do the same.  Because I know that ultimately by doing this, I'll end up learning much more from other folks that I could possibly teach them.

The end goal of course being that the clients we serve are getting the highest quality work possible.  But more on that in another post...  ;)

It's interesting to see what other developers value and/or what topics they are interested in regarding the development of software.  I'm going to start doing some internal presentations and live coding sessions at my company for my fellow consultants.  I've got a pretty long list of possible topics, but I offered up 2 topics today that pertain to some of the work I'm doing on my current project.

1. Examples of how to apply some of the core OO principles (i.e. SRP, OCP) in a real world application and some of the patterns that complement them (i.e. Decorator, Proxy, CoR).
2. Writing automated web tests using WatiN

Guess which one got the most response?  If you guessed #1, you must be working with folks who are passionate about writing clean, maintainable code, regardless of the technology.  Consider yourself blessed.  As for the rest of us, I'd venture to say #2 would usually be the most "popular" choice among developers.  At least that's the response I've received so far. 

Of course, learning (and showing) a new automated web testing tool is very cool and can be very useful.  I really like the Watix line of web testing frameworks. 

But I see much more value in learning how to adhere to some of "uncle Bob's" OOD principles (Robert Martin's site seems to be down, so that link is from Matt Berther) and how patterns can help us along the way.  I see so many bugs that pop up in existing systems that would be so much easier to find and fix if just SRP alone was applied at some level in the code base.  And even more likely, many of those bugs probably wouldn't have existed in the first place.  My recent experience has proven (once again) that the violation of SRP along with code duplication makes a fertile ground for those little "buggers" to grow.

<SRP tangent>

More and more, when folks ask me why I coded something a certain way, SRP has most likely influenced my decision.  I think SRP is one of the most important principles that developers should be applying when they are implementing new features and/or refactoring an existing code base.  The principle itself is very easy to learn. Code should only do one thing.  This can be applied as high up as the logical layer level all the way down to a single line of code.  How far you take it is answered in the usual "it depends" response.  The difficulty in applying this principle, on the other hand, can vary greatly depending on the code base and the comfort level of the team with other OO principles and the patterns that support them.

</SRP tangent>

Ok, I'm back.  So it sounds like I'm going to be doing the WatiN session first, but you better believe I'm going to be stressing the importance of writing good, clean code even for automated web tests.  They're not going to get off that easy.  :)

Just so folks don't think I'm coming off as elitist with my new little series, here's an oldie but a goodie from yours truly on my first .NET project way back in early 2002.  (And really, my first real programming project, since my previous life was mainly doing scripting/automation.)

And this is VB, folks.  <gasp>  (Notice the title change?)

cmd.CommandText = "UPDATE ATT_Circuits SET " & strField & "='" & strControlText.Replace("'", "") & "' WHERE Hostname='" & txtHostname.Text & "'"

Ok, so I don't think I really need to point out all the embarrassing problems in this one line of code.  Obviously it should be parameterized and that Hungarian notation just gives me the willies.  Oh and did I mention that I had this in right in the code behind for a web form?  Eeek!

In my defense, at the time (and some would say this is still the case), that's what Microsoft was encouraging.  Back then I didn't know any better.  But thankfully the many evening and late night hours I've spent over the past 5 years has allowed me to learn much better ways of building software.  <insert thank you to my wife here />  Of course, this process seems to never cease!  :|

Anyone else brave enough to share smells from their first software projects?  :D