Can you say that again?

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 …

Source: FlaccidScrum by Martin Fowler

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).

Advertisement

Why Software Development is a pain?

Because it depends!

Entangled by Jinx!, CC BY-SA 2.0.

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.

Jump-start Your Mind

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.

Now, go read it… it’s time well spent.

We Don’t Need No Regions

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.

The 10 Commandments for Writing Code

• Thou shalt not write code that you don’t know what it does;
• Thou shalt not write unnecessary code.

1512 Hours Without Internet

Tonight’s the night, that I’m finally back online after two months of being disconnected from the online world, at least while not at work, but that doesn’t count.

This was completely unplanned and caused by infra-structures problems from my new ISP, but they finally sorted it out and I’m online again.

Do Repeat Yourself in Unit Tests

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.

Application Prototyping Redux

Almost two months ago I talked about how to do application prototyping using the Pencil Project. However in the last couple of weeks I’ve tried out Balsamiq Mockups and I have to say that I’m very impressed.

Although being a non free solution the added value provided by Balsamiq Mockups more than compensates the initial cost. The feature that I think tips the scale for Balsamiq is that the process of creating a mockup is very simple and streamlined (The Quick Add works very well).

Last but not the least the simple hand-drawn look of the mockups is pretty cool and also transmits the right idea… “This is just a mockup people, criticize at will!”

Application Prototyping With Pencil Project

For the developers out there that sometimes like/have to pretend they are designers and need to create prototypes for graphical user interfaces the Pencil Project is an application to take in mind.

For starters, it’s free, unlike Microsoft SketchFlow or Balsamiq Mockups, which judging by the demo at their site seems pretty interesting but since I do some pretty basic stuff I don’t think it would pay off. Have to check their trial, though.

The Pencil Project runs as a standalone application or as a Firefox add-on. You can download it at the main site or directly from the evoluspencil code repository where you can also find more stencils packages.

Windows 7 – The Day After

To be honest it’s the day after the day after the day, but let’s not get lost in details. The main point is that I finally abandoned my old and trusted Windows XP for the new and shiny Windows 7.

Having stepped over Windows Vista I knew that this would be a big change but the reviews were good and I was really curious to try the new taskbar which by the way works very nicely. I have to say that I’m no fan of the Show Desktop button being on far right of the taskbar which could be a problem for me if it weren’t for the handy Win+D shortcut.

In terms of applications I haven’t had any compatibility problems although I changed my virtual drive software because with Windows XP I was using the free version of Alcohol 52% which triggered a warning in the Windows 7 upgrade advisor so now I’m using Slysoft Virtual CloneDrive.

The only thing that really annoyed me was the lack of a user interface to change the icon associated to a file type. Changing the default application for a given extension is easy, but if you want more control on the displayed icon you are out of luck. Thankfully you can download this awesome, at least to me, utility to quickly carry out this. Thumbs up to the creator of Types.

Sent from my Windows 7 computer…