Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much

Random thoughts on programming

by tilly (Archbishop)
on Feb 19, 2001 at 10:41 UTC ( [id://59345] : perlmeditation . print w/replies, xml ) Need Help??

As the title says, this is in no particular order, a number of random points about programming that I think are of exceptional importance.
  1. The most cost-effective method of testing is code reviews. This is true even before you count in benefits in terms of knowledge transfer etc.
  2. The bug is probably in your code. Failing that it is probably in something that changed recently.
  3. You are using version control software and have backups, aren't you?
  4. The hardest class of bugs, and one of the most common causes of failure for large projectgs lies in keeping track of interactions at interfaces. This has been known since the 70's and The Mythical Man-Month.
  5. Most software projects fail. The odds of failure rise sharply with how hard it is for one person to keep track of what is going on. The more people you have, and the longer it is expected to take, the worse your odds are.
  6. When we start a project we inevitably do not know as much as we will learn. Therefore we will make decisions that in hindsight would be better being changed. Plan ahead. If your interfaces hide information (as recommended in references like Code Complete) then you are going to have an easier time in revisiting decisions. This will be even easier if you have a good set of unit tests like the XP people recommend. (Thanks clemburg.)
  7. Programming is about keeping track of ideas. How can you make this easier on yourself?
  8. Have you thought through your boundary cases in detail? Methodically walk through your code and test them, you may be shocked...
  9. One of the most common errors is to reverse the meaning of a flag. This is both an easy error to make, and is hard to catch in reviews. But name variables as yes/no questions and you will almost never make this mistake. Consider starting the name of your next flag with "is"...
  10. Don't make an ass of you and me.
  11. It is typically impossible to list all things that could go wrong. It is generally fairly easy to list conditions under which your code should behave correctly. This observation has enormous consequences for how you should validate user input...
  12. The basic outline of a transaction is that you note that there is work to be done. create a private work area, work in it, and then when the work is complete you make it public. The really nice thing about thinking in terms of transactions is that virtually all failure situations are easy to handle, just log the issue, save your private space (directory etc) somewhere for later inspection, and abort the transaction. If you in addition make a habit of keeping track of work that needs to be done in a table and retry it periodically, you will be amazed at how the system tends to be robust in the face of unexpected problems. The relevance of these points might not sink in for you until the next time a complex sequence of steps breaks, leaving things in an inconsistent state...
  13. It is likely that more truly innovative ideas have come out of play than serious professionalism. Luckily great software does not need to be particularly innovative.
  14. That is a nice shiny wheel you just reinvented...
  15. ...on the other hand the world needs more than one type of wheel...
  16. ...but the best way to create a new wheel is generally to modify an existing one in unexpected ways. For instance though woodworking could have used a wheel earlier, they didn't get one until Tabitha Babbitt modified her spinning wheel into a circular saw (circa 1813 or so).
  17. That which is not automated does not reliably happen.
  18. Be sure you have error checks...
  19. ...but will your messages make sense if things do go wrong?
I know I missed plenty. So please add to the list.

Replies are listed 'Best First'.
Re: Random thoughts on programming
by japhy (Canon) on Feb 19, 2001 at 12:12 UTC
    The following are based on personal experience. Those marked with a super-scripted asterisk (*) are common mantras I repeat on #perl.
    1. If someone's already done it, respect it, investigate it, use it, and build on it.
    2. Competition is healthy. Fierce competition is not. Two people working on the same project is not two people working on conflicting projects. Don't Fear the Collaborator.
    3. Programming is about finding patterns. *
    4. Not understanding something is not always a reason not to use it. Not understanding an algorithm can be a sign of laziness or ignorance. Not understanding why you're using something is a bad thing. (Case in point, people that do use CGI qw(:standard) and have no idea why.) *
    5. Code that reads like "There was an old lady who swallowed a fly" needs serious rethinking. (That is, code that is highly redundant, in the form of A; A B; A B C;.)
    6. Code should be fluent. Don't program in a stuttering manner. If this means you need to read all your code before you add more, by all means, do so.
    7. Users are evil. All users are evil. Do not trust them. Perl specifically offers the -T switch because it knows users are evil. *
    8. It helps a bit to know that program XYZ received invalid data. It helps a lot to know that program ABC sent XYZ invalid data. Learn to use stack-tracing tools (for Perl, that'd be

    japhy -- Perl and Regex Hacker
Re: Random thoughts on programming
by damian1301 (Curate) on Feb 19, 2001 at 11:09 UTC
    20. Expect the worst - don't always think that the user's input will be nice, clean, and tidy.
    21. Always use die and warn(sometimes) if the code has a possibility of failing.
    22. DO NOT try to reinvent It is already good enough as is and should not try to be re-written. Check out chromatic's homenode and generally(.*?) just look at daily posts on why not to.

    I just thought I should point that out.

    Almost a Perl hacker.
    Dave AKA damian

    I encourage you to email me
(dkubb) Re: (2) Random thoughts on programming
by dkubb (Deacon) on Feb 19, 2001 at 14:52 UTC
    1. If you think you need to optimize, always profile your code first. Use Devel::Dprof for perl scripts, DBIx::Profile for DBI code, Apache::Dprof for mod_perl apps.
    2. Explore, Learn and Study CPAN. Look often at the recent uploads list. You never know when a module will come out that will allow you to re-factor out code from existing systems. Remember, even the most brilliant people understood the value of learning from those who came before:

      "If I have seen further it is by standing on ye shoulders of Giants." --Isaac Newton Feb 5, 1676

    3. Look at the source code of the CPAN modules you use. Worst case, you will learn some interesting uses for perl, best case you'll learn more efficient ways to use those common modules you thought you knew everything about.
    4. Format and comment your code as if you are going to return to it later for instruction. File the location of this code in your memory (or better yet docs), because if you need to do something similar you have a pre-existing code base. Learn to bootstrap your future development using custom made documentation and examples.
    5. Find a good text editor. Learn it well.
    6. Get involved in PerlMonks.
    7. The teacher will sometimes learn more than the student. By trying to explain a concept to another person, it's like you're learning it all over again.
    8. Keep everything as simple as possible. Write the least amount of code to get the job done. Just given the law of averages your likelyhood of making mistakes goes down. Besides that, the less you need to keep in your head at once, the more likely you are to understand the bigger picture.
    9. Understanding needs to come before automation, otherwise you will be doomed to solve your problem again, and duplicate the effort to re-automate it. I always solve the problem proceduraly before making objects, keep paper records before making a database, and design interfaces in HTML before making CGI's. Even though this doesn't always return perfect results, IMHO I believe the answer I come up with is usually closer to the ideal than without this methodolgy.
Re: Random thoughts on programming
by Tyke (Pilgrim) on Feb 19, 2001 at 15:10 UTC
    1. Start writing the test harness before you start writing the code you want to test... it can often clarify just what it is you need to do!
    2. From time to time stop and think. It's not a luxury!
    3. Don't be afraid to experiment with different ways to do things, not only might you learn something new; but you might also understand occasionally why your original code was better
    4. Take time to clean your code up regularly... in particular make an effort to be consistent even if it means going back and reviewing existing code. Be critical.
    5. Sometimes you need to work at being lazy. Learn how to use your toolset effectively. Add your own tools if you need them.

      Sounds like someone else has been reading Extreme Programming books. Numbers 1 and 4 on your list are very XP techniques :)


      "Perl makes the fun jobs fun
      and the boring jobs bearable" - me

        The what books? Sorry, for being trite, but the only XP techniques that these are based on are XPerience... very painfully earned for the most part.

        However, it's nice to know that someone else is pushing the same ideas out there :)

(crazyinsomniac) Re: Random thoughts on programming
by crazyinsomniac (Prior) on Feb 19, 2001 at 12:41 UTC
    6. Don't forget about scope.
    6. Make sure you're not forgetting about scope.
    6. Be sure your're asking for what you really want.
    6. Document that mother before you write it(or at least right after you do).
    6. Forget about voodoo, cause praying won't help. If you don't know what your code is doing, like the man said, figure it out.
    6. When all else fails, kick'n'reboot.

    Disclaimer: Don't blame. It came from inside the void
    perl -e "$q=$_;map({chr unpack qq;H*;,$_}split(q;;,q*H*));print;$q/$q;"

Re: Random thoughts on programming
by mothra (Hermit) on Feb 19, 2001 at 20:33 UTC
    My $0.02:
    • Learn the idioms of the language you're using. Respect them. USE them! This seems to do wonders for improving the readability of your code, and makes it easier to put your ideas into the "words" of the language you're using.
    • Know when to/don't be afraid to put your code into functions. For me at least, 3-4 40-50 line functions are almost always easier to understand than 1 big honkin 200 liner that often seems to look ugly and repetitive.
    • Focus on producing *good quality* code, with less of an emphasis on how quickly you can churn it out. I learned that from this node. :) It's amazing how lots of careful thought about a problem, without doing any (or very little) coding during that thought process can suddenly turn into an elegant solution.
Re: Random thoughts on programming
by danger (Priest) on Feb 19, 2001 at 19:51 UTC
    • Use a thought-processor before a text processor/editor (my preferred thought-processor is a rotring 600 pencil and a pad of graph paper)
    • Document your data and design, not the code.
    • If you are planning to throw one away, throw away that plan.
    • Be sure your tests cover what the code is supposed to do, not merely what it does do (writing the tests first, ala XP, is helpful here).
    • Step away from the code ... regularly!
Re: Random thoughts on programming
by flay (Pilgrim) on Feb 19, 2001 at 14:23 UTC

    Prototype, prototype, prototype. Or, as Fred Brooks put it:

    `Plan to throw the first one away, because you will anyway.'

    flay, here to learn

Re: Random thoughts on programming
by dws (Chancellor) on Feb 20, 2001 at 02:00 UTC
    7. Programming is about keeping track of ideas. How can you make this easier on yourself?

    A corollary:
    47.   Programming is often a matter of keeping track of loose ends. Establish a convention for tracking yours (e.g., #FIXME) and use it religiously. A loose end that you don't fix before shipping is an embarrasment waiting to happen.

Re: Random thoughts on programming
by robsv (Curate) on Feb 19, 2001 at 21:19 UTC
    Seeing tilly's #5 random thought ("...The more people you have, and the longer it is expected to take, the worse your odds are.") reminds me of what often happens when software projects are behind schedule. When a software project is running behind schedule, and people "add manpower" (in the words of Fred Brooks) or "throw bodies at the problem" (my description), it often just makes matters worse. Brooks' law states that "Adding manpower to a late software project makes it later". If you're managing a software project that's running behind and are tempted to add resources, remember Brooks' warning: "When schedule slippage is recognized, the natural (and traditional) response is to add manpower. Like dousing a fire with gasoline, this makes matters much worse."

    - robsv
      I recall being taugh much the same early on in my programming career. The example give to me was:
      "You cannot make a baby in one month by impregnating nine women:"
Re: Random thoughts on programming
by Maclir (Curate) on Feb 20, 2001 at 02:14 UTC
    A few thoughts:-
    1. Programmers will test their code to make sure it works. Users will test code to see where it breaks.
    2. Always look to see where you have hard coded limits. Things like numbers of variables in some array or structure, maximum / minimum values, things like that. Make them at least a globally defined value, so you only have to change things once when the user will (eventually) say "now could we make it do this . . . ".
    3. Data validation - it is easier to assume all data is wrong, and test to see if it is correct, than to assume it is correct, and look for errors. This, of course, sits well with the taint concept. And if the requirements change ("well, can we now handle negative rates of growth?"), you only need to add an additional validation test, or modify an existing test.
Re: Random thoughts on programming
by Albannach (Monsignor) on Feb 20, 2001 at 02:27 UTC
    One of my favorite goals which appears to sum up several of the more specific ones stated earlier (simple to state but not so simple to implement):

    A program should always gracefully survive even the worst data.

    Whether it carries on unperturbed with a warning message in a log, or dies but clearly spells out why (and does not frag the disk), will depend on the specific nature of the application. I was reminded of this today while trying to load a corrupt spreadsheet into Excel (which breaks all the rules 8-( ).

    I'd like to be able to assign to an luser

Re: Random thoughts on programming
by el-moe (Scribe) on Feb 20, 2001 at 08:36 UTC
    42. When debugging is getting you down, go outside and look at the sky or the trees or the ocean... anything but text.

    Take a deep breath or five and remember that you know what's wrong. You just need to look at your code with someone else's eyes... even if they belong to you...


Re: Random thoughts on programming
by petral (Curate) on Feb 21, 2001 at 02:41 UTC
    A propos of #5, this from Dr. Haussler, professor of computer science:
    "He's unbelievable. This program represents an amount of work that would have taken a team of 5 or 10 programmers at least six months or a year."
    From NYTimes Tues 13 Feb 2001.
    Talking about James Kent who, in 4 weeks, wrote code to integrate the Human Genome Project's data and thus stay in step with the attempts to do it commercially.

      It's worth noting that Kent had to ice his wrists at night. A codefest like the amazing one he pulled off isn't easy on the body.
(ichimunki) re: Random thoughts on programming
by ichimunki (Priest) on Feb 20, 2001 at 03:15 UTC
    Hmmm. All kinds of great thoughts and no has stated rule #0: "Have fun-- Programming is fun!"

      No - if programming was fun, then I would feel really guilty (well, maybe a little guilty) about accepting the obscene amounts of money that are showered upon me for cutting code.

      At least we need to feel a little seriousness for it to count as work.

Re: Random thoughts on programming
by johndageek (Hermit) on Aug 12, 2003 at 20:37 UTC
    Enjoy the journey of life, learn from each moment.

    All points in your life intersect through you.
    Think of all that experiences you have, to combine in ways that have never been tried before.

    Brilliance is just a matter of combining experiences and ideas you have had applied in ways no one else has thought of in a particular situation.

    They pay me for those momentary flashes of brilliance each day.

    Listen to the request for help.
    keep listening - do not assume you know the answer and start contemplating a solution.
    Ask for clarification, claiming ignorance - You will be amazed at how often that claim turns out to be true.
    Speak to others with needs for the same types of help, your expanded insight will improve your solution.
    Mentally solve the problem 3 ways, using only existing programs and systems.

    Decision time: to code or not to code, that is the question.

    If the solution can be implemented without code - GREAT, it's done. and you can move on to other cool things.

    If the solution needs coding - GREAT, you now have a program that really needs to be written, using all the neat techniques and skills you possess, or will possess because you have need to epand your boundaries.

    Elegance: the simplest solution with the best performance that will work for the most people at the lowest cost.

    Solution test suite: Would I want to use my solution to do my job every day in exactly the way I am asking others to use it?


Re: Random thoughts on programming
by prodevel (Scribe) on Feb 26, 2001 at 11:51 UTC
    If you're a code mentor (you have low-level coders, whether they be DB, JAVA, J++,
    JSP, ASP, PHP, SOAP) coders looking for DB info, always ask what their project is,
    not what they're trying to do at the moment. I've had way too many interactions
    w/newbies trying to work around problems w/me as a shepard.

    When I circumvented these situations, eventually, by systematically asking detailed q's,
    I've been able to solve any simple problem I've come against.

    This has saved me enough time to POST to this heavenly subj.,
    even though there were so many BRILLANT responses.

    Just wanted to add what <italic>little</italic> I could.