NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
--Larry Wall in perl.c from the perl source code
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Understanding the problem (Score:1)
The bigger the project, the more important to have someone breaking the big problem into logical smaller problems. Even then, I think everyone needs to understand the larger problem.
This is where I might find some fault with Microsoft as an exa
Re:Understanding the problem (Score:1)
This is exactly how I feel.
Code is always a trade-off. It always caters to some cases better than to others, because there is never any single way to do things that would always be best. Of course, I'm not saying anything new — this is why Extreme Programming proposes what it proposes, and why it embraces constant refactoring as a way of life for a project.
What is important, is to be aware of the trade-offs. That requires a solid understanding of the problem first; it's okay to parse HTML with simplistic regexen, so long as you know exactly how your input data is structured, and sometimes even if you don't, as long as you make sure that it's not impossible to come back to this bit of code later and fix it up.
“If it's stupid and it works, it's not stupid” actually sums this up nicely: the catch is, do you know it works? If so, well then of course, it's not stupid.
Reply to This
Parent