Re: Re: Re: Perl Destroys Interview Question

[redsquirrel]

Here are the requirements I was given...

Program Purpose

The goal of the program is to count the occurrences of all words in a file, and write this count into a new file.

Requirements

• The input file will contain 1 word per line (lines will be terminated by the newline character), and the file will contain an arbitrary number or lines.
• The file will be terminated by an end of file character.
• The word count must be case insensitive, as there may be varying case throughout the file.
• The output file must write each word once, and include the number of occurrences of that word on the same line.
• The lines in the output file must be sorted in ascending order.

Sample Input:

Chicago
Paris
chicago
London
red
blue
Green
Red
REd
london

Sample output:

blue;1
Chicago;2
Green;1
London;2
Paris;1
red;3

[mr_mischief]

So your original solution works for the narrow scope of the requirements. It fails if the requirement that there is one word per line is changed. This explains perfectly why the questions above arose about lines versus words -- according to the spec, they can be considered the same.

Now only one question remains. Do you code to exactly match a questionable spec? Or, more to the point, wouldn't it be better to code something which works according to the exact spec plus gets the behavior right if the questionable part of the spec is changed?

I think that when possible, a restrictively narrow spec should be answered with a more general solution which works for the spec at hand and future likely changes. In some instances, the future likely cases are hard to determine. In this one they are not. In the spirit of a job interview, I'd like to see either both ways implemented, or a comment in the code that one way was chosen over the other because of the nature of the spec.

Of course, redsquirrel, since you already went above and beyond what the question asked it wouldn't be fair to complain that you didn't do even more work. I'm just making points about more general cases again. ;-)

Come to think of it, it seems that much of my life as a programmer, and even much of my life besides programming (and probably because of habits learned from programming) is about making solutions which already work for one case more general. I think this is probably a goal of a large percentage of programming effort overall.

Update: fixed a tpyo.

[ihb]

How does this play along with XP (Extreme Programming)? I'm not too familiar with XP myself nor do I have any experience in it, but to my understanding you shouldn't make the general solution if you want to be an extreme programmer. The reason for that would be that it's likely that the spec would be altered in such a way that even your general solution wouldn't solve the new problem. Then you've solved something that wasn't a problem for you to solve, and hence done unnecessary work. The planning for the future would be done by other techniques (such as having well refactored code).

This is how i interpret the XP philosophy. I may very well be wrong. Please correct me if so.

ihb

[mr_mischief]

My understanding of XP suggests you're right. However, no methodology is 100% right in every situation.

I think that doing a great deal of work to generalize something when there's no need is obviously silly. There's no reason though to do something in a less general way which doesn't run any faster and requires just as much work to implement. I'm talking about looking at the problem as a more general case, not about working a more general case into the code as an afterthought.