I’ve been trying to precompile JSPs today. They reference custom tag libraries. What a joy…

There’s something to this BDD kool-aid that people have been drinking lately…

In the great repositories of programming errors I found this little jewel. Aren’t we glad we had all those comments to guide us?

This is another way that comments become lies over time: nobody maintains them. Nobody maintains them because they litter up the code and programmers have to learn to look past them to see what code is doing. Sometimes we have to page down through a lot of them to find a useful bit of code. It’s why we’re glad for syntax highlighting, so we can more easily ignore them all.

The answer is probably not to write more comments, or to write them in a catchy style, or to demand that programmers look at them more carefully. Probably the answer is to obviate them (write them into the code) and delete them. We are all trained to look rather carefully at the code.

Looking at this example, can you tell why the parental control is set to three? Probably not. You could guess. More likely, you would agree if it were set to DEFAULT_SAFETY_LEVEL, but if DEFAULT_SAFETY_LEVEL is 3 you are no better off.

But what if there were constants like NO_FILTERING, MODERATE_FILTERING, and STRICT_FILTERING and DEFAULT_FILTERING_LEVEL were set to STRICT_FILTERING, and the variable were ‘parental_filtering_level’? Then there is a lot more information available to you. So you’d delete the comments. When you were testing DEFAULT_FILTERING_LEVEL would be NO_FILTERING, later you would change it to MODERATE_FILTERING , and maybe pre-release you would set it to STRICT_FILTERING. The change and its check-in comments would tell the whole story.

That having been said, I don’t know that I have interpreted the variable and setting correctly. Even having comments doesn’t tell me what the variable and the value ‘1’,’2’, or ‘3’ really mean.

This is what I mean when I say that I don’t like comments. They need to be obviated first, and then deleted. Sometimes it is even best to delete them all, and then try to figure out the code as a means of training oneself to write more descriptive code.

If the code cannot express itself, then a comment might be acceptable. If the code does not express itself, the code should be fixed. Either way, obsolete comments and those that do not add value should be dropped like a hot rock.

I recently heard it suggested that large scale software projects should be built 3 times before releasing them:

• once to prototype
• once to prove out design
• once with the intent of release.

Today I heard this quote from Monty Python:

“I built a castle in the swamp and it sunk. I built a second castle and it sunk too. I built a third castle and it burned down and then sunk. But the fourth castle, Ahhhh! That one stood.”

Maybe they were on to something…

I stumbled across another interesting article today on our inability to plan ahead, specifically to determine in advance what will make us happy later on.

One group has to choose which sandwiches they want for an entire week in advance. The other group gets to choose which they want each day. A fascinating thing happens. People who choose their favourite sandwich each day at lunchtime also often choose the same sandwich. This group turns out to be reasonably happy with its choice. Amazingly, though, people choosing in advance assume that what they’ll want for lunch next week is a variety. And so they choose a turkey sandwich Monday, tuna on Tuesday, egg on Wednesday and so on. It turn out that when next week rolls around they generally don’t like the variety they thought they would. In fact they are significantly less happy with their choices than the group who chose their sandwiches on the day.

This is hardly a surprise to any veteran of software development. It doesn’t prove that all planning is a waste of time (of course not!) but it shows that it’s hard to guess what we’ll want next week for lunch. I am surprised we ever know what we’ll want next year in software.

Software people for years have complained that users don’t know what they want and that the requirements keep changing. Of course they do, and of course they always have. The existence of an automated system changes any practice, and changes the set of things a practitioner will desire to do next. This has been the basis for rapid development and agile pratices for some time. It underpins the whole spiral/iterative model.

Just an observation: it is deucedly hard to plan to be happy in advance. It is hard enough to be present in the moment, and to take advantage of the opportunities that come your way. We should plan, and we should prepare (hopefully better than I do) so that we’re ready for the opportunities that come for us. We might even create a few opportunities. But we shouldn’t be surprised in a world as complex and variable as ours that we can’t nail down the future exactly, in software requirements or career planning.

We’ve been working on new course materials lately. The other day we were discussing the bad dependencies in code that can occur when the Interface Segregation Principle (ISP) is violated.

We started calling these dependencies phantom dependencies. Here’s why…

I'm having an discussion on comp.object at the moment about whether or not quick and dirty solutions are really quick.

There is an old adage that good things come to those who wait, provided they work real hard while waiting.

I read a blog article today that made me sad. The blogger mentioned that they were doing TDD and using Clean Code techniques and building a working system. His company, apparently distrustful of the newness of his approach, hired a consultant to come and critique the team’s code. I like that the company lets the team try new things, and that they decided to check on the team’s results. So far, this is all good.

Here’s the sad thing: the consultant (allegedly) made a number of old-school recommendations based on practices that have been obviated.

Someone on comp.object recently asked why anyone would make a field private since privacy ruins extensibility.

Microsoft’s forthcoming C# version 3 has some innovative features, as described in this blog. I give the C# team credit for pushing the boundaries of C#, in part because they have forced the Java community to follow suit. ;)

A common tension in many development shops is how far to trust the developers with languages and tools that are perceived to be “advanced”. It’s tempting to limit developers to “safe” languages and maybe not all the features of those languages. This can be misguided.