eCrane Blogging

This week’s issue of Code Project included a poll question. The question was: “Do you limit the width of your source code? 76 columns? 100 columns? Anything and let word wrap deal with it? How do you swing?” The results were:

Yes, so that it can be printed easily, 6.09%
Yes, so it fits on my screen, 48.59%
Sometimes yes, sometimes no, 28.04%
No, 17.28%

I was surprised that the list of possible answers didn’t include anything about readability. Code readability is a big issue and long lines are harder to read, whether it be in a novel or in code. Code should be formatted so that it can be read!

I have lately had opportunity to review other people’s applications and source code, and there’s something that I just don’t get. After all the books, magazines, blogs, thinking and discussion about best practices, standards and the like, why in the world do so few developers actually pay them any heed? Why, why WHY!?! And I’m not talking about having a very heavy development process with all kinds of long written documents. I’m just talking about having some kind of program specification, some kind of testing plan, even writing code comments.

One of the excuses that I hear a lot is that “we don’t have time for that.” But in several ways, time is a lame excuse. Take code comments for example. If you are only thinking about typing extra characters, it makes some sense to say it takes longer. But typing is not the hard part! The act of writing some code comments for a function or a class can help the developer to clarify the design. I think it is more an issue of habit than of time. Once in the habit of writing code comments, it doesn’t really add more time. If anything, writing the comment first can help to structure the code and can actually speed things up. The other factor is of course that having good comments can make code more understandable to users and hence more valuable in the long run.

Another good example is unit tests. Sure it takes a bit more time up front to write a unit test. But in the long run it can save time. And not only that, but it improves the quality of the code and gives much more confidence in the application. So to use time as an excuse not to write unit tests is really hog wash.

Again and again I meet coders who shun all process, standards and best practices. They think that only the running application is what matters. In a very limited way, they are right. But this is really what separates a hobbyist from a professional developer. The professional developer is interested in the full application life cycle. When considering the full life of an application it is hard to justify NOT writing code comments, unit tests, and a minimum of supporting documentation. These are just the starting point for a professional. I don’t mean to be disparaging of other developers. But I’m tired of seeing sloppy work, poor quality and lame excuses. I want to have pride in what I do, and I could never take pride in some of the code I have seen recently. I thank that sounds harsher than I mean it to. It wouldn’t bother me as much if there were an accompanying desire to improve and learn. But when sloppy work is compounded with a smugness and arrogance it aggravates me.

The daily scrum meeting is part of the Agile development methodology. A google search will reveal a lot of web resources on the topic. To summarize, a scrum meeting is a short (15 minutes), daily team or project meeting with some particular characteristics. The most significant of which are that only team members can talk. Management can be present and observe, but not speak. All discussion should be taken off-line after the meeting. The meeting is conducted standing up. Team members answer three question:

What have you done since last meeting?

What are you going to do before next meeting?

Is anything impeding your progress?
I have come up with ten reasons to have daily Scrum meetings. They are:

10.  It’s good to stand up and stretch for a few minutes.

9.  The meetings don’t take long, freeing time for more important things.

8.  The project manager does not get to talk.

7.  Team members get equal opportunity to talk.

6.  The name comes from rugby. If you have never watched a rugby match you should.

5.  The regularity of the meetings promotes team cohesion and consistency.

4.  It is obvious if someone on the team isn’t doing their share of the work.

3.  The meetings help facilitate team communications.

2.  Scrum meetings help people set and achieve short term goals.

…and the number one reason to have a Scrum meeting is:

1.  ‘Scrum’ is a cool name for a meeting.