Re: Linear programming is bad

[chromatic]

I am certain Ovid knows this, but it's worth presenting a counterpoint. I have two rules for this situation:

• Code should be as maintainable as possible at all points in the development cycle.
• Code should do only what is absolutely necessary at the current state of the development cycle.

By maintainable, I mean that the intent of the code is evident, there is no duplication, and the names of items and any comments are sufficient so that a decent programmer can fix bugs or add features.

By absolutely necessary, I mean that there is no code that "might be used at some point in the future". If you don't need a feature now, don't pay for it yet. If you're writing an IRC client, don't add a web browser until it's absolutely necessary.

The not-so-subtle difference is that I argue to put off taking advantage of the possibility of modularity until you actually need to re-use a function or an object elsewhere. It's hard to convince me to invest in something that doesn't have an immediate benefit.

[cjf]

Your points seem to fit rather well with Extreme Programming ;-)

I agree with you that unecessary features should be avoided. I also agree with you that code should be as maintainable as possible during all stages of development. What I disagree with you on is the priority of the two and how they interact.

I would have broken Ovid's code down into subroutines like he did in the second example in his post. I find code in such a format is far easier to maintain and ultimately saves a lot of time. So if the modular version of the code is more maintainable, then in order to adopt its use, the benefits of increased maintainability should outweigh the costs of adding a 'feature.'

Let's examine the costs then. There are three reasons why I avoid adding features that are not absolutely unecessary:

1. It introduces more potential bugs and in doing so can greatly reduce the usability and security of the product.
2. It wastes time and money for features that may not ever be used.
3. It makes the codebase harder to maintain. This is especially important in open source projects where you want to attract developers. If your code is a bloated mess they're far less likely to get involved.

If at the beginning of a project you decide to modularize the code, you will not be introducing any additional bugs. In addition, if modularity is put off until later, and then required, programmers may introduce new bugs during the transition.

Number two may partially apply. It may take extra time to set up the program as modular (then again it may not), but this time is not spent on a wasted feature, it is spent on making the program more maintainable and reusable. Assuming you agree that modular code is more maintainable, number three gives the advantage to modularity as well.

So you have to weigh a possible small price/time increase against greater long term maintainability. I find that I consistantly value maintainability enough to spend the extra time modularizing my code.

[chromatic]

There is a definite tradeoff, and it would be silly (or arrogant) for me to write an authoritative rule. Your point about adding modularity potentially introducing bugs is spot on correct. Of course, test freaks would suggest that unit tests will catch that. (Hopefully...)

Besides the complexity concern, I hate to be stuck with a bad interface for backwards compatibility reasons. If you modularize too early, there are two yucky possibilities. Either your interface is too limited for the general uses and you'll have to rewrite code anyway, possibly creating bugs, or you'll have to write an overly generic interface, adding more complexity in the hopes that you'll catch all the ways you might want to call the function.

In my experience, by the third time you use a piece of code, you'll know enough to write a good interface.

Besides all that, the cleaner your code, the easier it will be to modularize. By the time I get over 100 lines, generally I'm writing functions anyway. There's a definite intuitive understanding that's not coming across in my posts very well...

[Louis_Wu]

One way to write Ovid's program is to ask yourself what you have to do with this code.
1. Get the expense info.
2. Munge the info; in this case, sort by department.
3. Write a report.
Once you know what you have to do, you might be able to write the very beginning of the program. In this case, you can write the 3 lines which use the functions you will write later. And if you follow BrowserUK's advice, you can write 'functions' which print OK.

You've only written code that you need to write - the function names came right out of your task description. The functional nature lends a bit of maintainability. And it keeps you honest about what you're trying to do.

---

Perl programming and scheduling in the corporate world, as explained by dragonchild:

"Uhh ... that'll take me three weeks, broken down as follows: 1 day for coding, the rest for meetings to explain why I only need 1 day for coding."