Thursday, April 10, 2008

Simple vs Easy Revisited

New client, new project, new developers - same old story on code monkey approach to designing and implementing objects.

I am again gently enforcing these two simple rules:

The objects must be simple to use, not (just) easy to make. E.g. do not expose a date as string even if XML xs:date types becomes strings in .NET and strings are easy to code for you - rather make it simple to use the object by converting the string to and from a real .NET DateTime value.

There is no such thing as "throw-away code" if it enters the source control system. You will not have time, due to time preasure, to come back at a later time to do things right in throw-away code that you write due to time preasure. Therefore all code that you check-in must be production quality code.

In addition, I try to enforce this principle: There should be no green code (comments) in the code. All comments should be considered a missed opportunity to use 'Refactor - Extract Method' and use of the comment as the basis for the new method name.

2 comments:

yaronn01 said...

I also push to make "green code" obsolete in my team but not everyone like it. Can you give me a few "how to convince your boss to drop comments" tips?

Kjell-Sverre Jerijærvi said...

Well, here in Norway bosses don't have the power to change the mindset of developers; so I convince one developer at the time during everyday work.

Don't keep "can come in handy" code block if you have a source control system, the YAGNI principle applies to it anyway.