I always like to point out that it isn’t methodologies that succeed or fail, it’s teams that succeed or fail. Taking on a process can help a team raise its game, but in the end it’s the team that matters and carries the responsibility to do what works for them.
Teams that fail will probably fail whatever methodology they mis-apply, teams that succeed will build their practices on good ideas …
Today, over lunch, this subject was mentioned midst a lively talk about how some people can be so completely focused on processes that they completely miss the bigger picture and now a link to this, somewhat old, bliki entry surfaced on my Twitter feed so I felt compelled to spread the word in any way I can.
You should forward this to all those pointy-haired managers out there who don’t read my blog (which is justifiable), but seem to also not know about Martin Fowler (for which there is no excuse).
Joke aside, I find that the most difficult challenge developers struggle with is that most things that really matter in terms of impact on the success of a software project depend on guidelines, patterns, best practices and whatever other name you may call it.
Every time I hear someone defend some piece of code with a pattern or a guideline I keep hoping to hear the real justification behind it, like what does the project gain from adopting this guideline or following this pattern, but people generally stop at the pattern/guideline reference.
C’mon folks, that’s not enough, we call them patterns, guidelines and best practices for a reason… they are applicable in a given context and will most likely help you, but they cannot be applied blindly. Otherwise, they would be called rules and software development would be a breeze.
For example, just because someone says to prefer interfaces over abstract classes you should not hardcode in your subconscience that an interface will solve all your problems. In the same tone you can always solve a problem by adding another layer of abstraction, except when your problem becomes to many layers of abstraction.
Another one of my favorites is the quest on eliminating any possible duplication. Don’t get me wrong, I totally believe in DRY but you need to have some common sense because if two things are the same now but may change due to completely different reasons you should carefully evaluate if you gain anything from trying to avoid the so-called duplication.
You should do stuff that helps you tame the complexity of the software you’re developing even if it contradicts one or more guidelines or best practices. If you want to know more on this subject, you should read Code Complete by Steve McConnel, it’s a pretty big book, but totally worth it.
I haven’t written in a while mostly because I’ve spent my time reading what others wrote and today I’m writing purely motivated by what I just finished reading.
Mindfire: Big Ideas for Curious Mind by Scott Berkun was such a pleasure to read and ended up igniting parts of my mind which I have to admit were becoming a bit numb that I felt the urge to take some time to first say thank you to the author and then recommend it to all your curious minds out there.
If your code reaches a level where you want to hide it behind regions then you have a problem that regions won’t solve. Regions are good to hide things that you don’t want to have knowledge about such as auto-generated code. Normally, when you’re developing you end up reading more code than you write it so why would you want to complicate the reading process.
I, for one, would love to have that one discussion around regions where someone convinces me that they solve a problem that has no other alternative solution, but I’m still waiting. The most frequent argument I hear about regions is that they allow you to structure your code, but why don’t just structure it using classes, methods and all that other stuff that OOP is about because at the end of the day, you should be doing object oriented programming and not region oriented programming.
Having said that, I do believe that sometimes is helpful to have a quick overview of a code file contents and Visual Studio allows you to do just that through the Collapse to Definitions command (CTRL + M, CTRL + O) which collapses the members of all types; if you like regions, you should try this, it is much more useful to read all the members of a type than all the regions inside a type.
Don’t get me wrong I’m a big supporter of the DRY (Don’t Repeat Yourself) Principle except however when it comes to unit tests. Why? Well, in my opinion a unit test should be a self-contained group of actions with the intent to test a very specific piece of code and should not depend on externals shared with other unit tests.
In a typical unit test we can divide its code in two major groups:
Preparation of preconditions for the code under test;
Invocation of the code under test.
It’s in the first group that you are tempted to refactor common code in several unit tests into helper methods that can then be called in each one of them. Another way to not duplicate code is to use the built-in infrastructure of some unit test frameworks such as SetUp/TearDown methods that automatically run before and after each unit test.
I must admit that in the past I was guilty of both charges but what at first seemed a good idea since I was removing code duplication turnout to offer no added value and even complicate the process when a given test fails.
We love unit tests because of their rapid feedback when something goes wrong. However, this feedback requires most of the times reading the code for the failed test. Given this, what do you prefer? To read a single method or wander through several methods like SetUp/TearDown and private common methods.
I say it again, do repeat yourself in unit tests. It may feel wrong at first but I bet you won’t regret it later.