Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation
 
PerlMonks  

How not to code

by brian_d_foy (Abbot)
on Oct 21, 2004 at 20:03 UTC ( #401293=perlmeditation: print w/ replies, xml ) Need Help??

Most people seem to most enjoy the actual coding part of the software lifecycle. Some people may have heard of design, and even non-programmers know about this part called debugging. It's the creation of new program statements that is the most fun though, and since it's so fun, we gravitate towards that part of the process and do it as much as we can. Damn the torpedoes!

This isn't a complete list of code avoidance techniques, and I'm sure plenty of monks will have their own to share.

This meditation is about taking all the fun out of programming. The fun part causes all the problems: it's the one the creates more lines of code which leads to more bugs and more work for maintainers and documenters. Life would be grand if every task could be expressed as a screenful of code (assuming that we don't have to worry about any of the code behind the statements we actually see). We'll never acheive that, but we can still work towards it.

For this meditation, I mean "programming" in an over-arching sense, including the entire development cycle, including the boring bits. I mean "coding" as just the bits that involve typing new statements.

"Not programming" means not coding when I don't need to. It's more than not reinventing the wheel, or Laziness. It's not about code style, code re-use, script archives, or any other source of code. It's also not about refactoring or reducing the amount of code, because that's coding too. "Not programming" means not doing anything. It means not creating more code, however we acheive that.

Do something else

The trivial solution is probably the most fun and the least well-paying. Just don't code. Play Quake. Watch a movie. Do something else. You could even do what I'm doing right now: write something for Perl Monks. It's a colossal <s>waste fo time</s> procrastination leverage technique that combines the synergies of the ... sell it anyway that you like, because you probably already know how to. This isn't a meditation on writing though: it's about not coding.

Don't get interns to do it for you

A lot of people see interns as less-than-minimum wage workers who will do just about anything to get a good letter of reference. Give them any real work to do and they'll probably take three times as long as anyone else and you'll have to redo it yourself anyway.

Of course, with proper supervision, interns and junior coders can do a lot of good work, too. They can pump out a lot of lines of code for a little bit of money. Don't think that they are just coders you pay less, though: how many of those lines did you actually need?

The same goes for outsourced programming: you can't expect good results when you dump something into the laps of people you have never met, never talk to, and generally ignore. Despite what managers may tell you, this does not save you money. Often it costs more, and you end up coding it yourself, and that's what we're trying to avoid.

Don't rush to code

If you don't want to do much coding, don't be in such a rush to code. Pressure-ccoker shops that need one-offs in 15 minutes (yes, they exist) don't count, just as many other situations will not fit this.

When we start coding before we really know what we want to do, we often end up with something we don't want or is a lot more than we should have to maintain.

I used to have a guide at one of my workplaces: a good idea will still be a good idea in three days. Not only that, you'll still want the good idea is three days. The fair and bad ideas will sort themselves out in your head within that time. You'll either see the downside or just forget about it completely. In that case, you didn't do any work.

Of course, we don't want to go the other way either. We don't need to make all sorts of fancy diagrams, UML charts, story cards, or any of the other things that delay coding.

If it ain't broke, don't fix it

Some people can be satisfied with ugly, kludgey code. Some people can't sleep at night unless every equal sign lines up correctly. Guess who spends more time programming (I don't know either: one probably spends more time debugging while the other keeps fiddling with things that don't make the code work any better).

If the code is doing whatever it has to do, let it alone unless you really, really need to change it (see the "Three Day Rule"). There is usually enough work to go around anyway. Do something else. Delay and evade pressure as long as possible.

Inherited code is another story. I haven't heard too many people rave about the beauty of the code dropped in their lap. More often than not, they complain about the long gone employee who was the only one who understood the code, or why anyone would try to code FORTRAN in Perl.

It's probably already there

A while ago, I thought "Wouldn't it be great if I could process a whole directory of Template files all at once?" I almost started to write the simple scrip that would be able to do it, but then I thought "I bet someone has already done this." Indeed, Template comes with ttree, which does just that.

There are probably a lot of things that you already have and just don't know about. Find and use those things.

Redefine the problem

Sometimes I can simply re-define the problem. Does this really need to be so complicated? Why are we really doing this step? Business processes develop over time through the hands of many people, some of which may have become a faded memory. The process keeps going because it has always happened that way and everyone assumes that everyone else wants it to happen that way.

Consider a social solution

Along with a problem redefinition, there might be a better way to re-arrange the people portion of the problem. If everything were just technology, wouldn't the world be great? We could solve all of the problems pretty quickly.

I get to see a lot of different situations since I get to visit so many companies while working for Stonehenge, and one of the most common situations is that the programmers don't work with the system administrators, or the other way around depending on which side you take. If that weren't enough, throw database admins into the mix, because they count themselves as a separate group. There might even a couple of levels of management in there, or even worse, grumpy off-site telecommuters.

It doesn't matter who's who, who's right, who's left, or who's to blame. Most likely the different groups don't even really know each other. They may not have even met. Companies and universities can be big places, so people are spread out. A lot of programming may just be working around something that someone else has set up. In some cases, they might have no particular attachment to that set-up (or, more likely, they do).

People tend to work better together when they know each other. People tend to work better with you when you've helped them out in the past. They work really well if they are drinking buddies. Maybe the solution is really just a night at the pub with the right people.

Get a different job

No, really: get another job. Many programmers promoted into a managerial career path find they no longer have time to code. And they probably get paid more.

--
brian d foy <bdfoy@cpan.org>

Comment on How not to code
Re: How not to code
by gex (Scribe) on Oct 22, 2004 at 01:38 UTC
    The same goes for outsourced programming .... Despite what managers may tell you, this does not save you money. Often it costs more, agreed -- point taken -- and you end up coding it yourself, and that's what we're trying to avoid. Actually no, that would be gainful employment.
Re: How not to code
by pg (Canon) on Oct 22, 2004 at 03:35 UTC
    "Do something else"

    I personally prefer design, which I found, gives me much more oppotunity to explore different technologies. And you actually got a group of people to try out different things for you. You are learning what a group of people learnt, not as detail as they do, but you do get a better chance to understand what technology is right for what, unless you are lazy, and do want to spend the effort. But from time to time, I have to code to satisfy my itch fingers ;-)

    "Of course, with proper supervision, interns and junior coders can do a lot of good work, too."

    Supervision is important, but it is probably more important to understand the person you are supervising. Each person is different and their skill set is different. I had the experience where junior was given tasks that exceeded her ability too much, and I ended up with coding for them the last minute. Challenge them, but make sure the tension is at the right level.

    "Don't rush to code"

    100 agreed! Even with a tight schedule, don't rush. If you rush, the schedule ends up more tight, as therr is a increased chance that you have to go back to revisit some of your requirements and design, and trash some of your code. If that happens towrads the end of your project ...

    "Business processes develop over time through the hands of many people, some of which may have become a faded memory."

    IT people should be involved in redefining business processes, together with business users. Computer is not only a tool to automate things, but also to redefine things. If all what you do is to make stupid things happen faster and quicker in a automated way, rethink!

Re: How not to code
by DrHyde (Prior) on Oct 22, 2004 at 10:04 UTC
    Get a different job

    Many programmers promoted into a managerial career path find they no longer have time to code. And they probably get paid more.

    Fuck becoming a manager. Fuck better pay. On days like yesterday, when the programming just wasn't fun, I want to go back to being a bus conductor. *That* was the best job I ever had.

Re: How not to code
by zentara (Archbishop) on Oct 22, 2004 at 12:12 UTC
    Of course, with proper supervision, interns and junior coders can do a lot of good work, too. They can pump out a lot of lines of code for a little bit of money

    Yeah, I'll confess...I don't write anything....I have a couple of "highschool hackers from Bangladesh", who I pay 10 cents per day. :-)

    Seriously, one thing I have learned is to always set any code aside, and come back and test it a day or 2 later....it's surprising how you can get "too narrowly focussed" during a single coding session, and a few days later, your perspective changes.


    I'm not really a human, but I play one on earth. flash japh
Re: How not to code
by bwelch (Curate) on Oct 22, 2004 at 13:49 UTC
    "Don't rush to code"...

    This part makes sense to me. One can do the initial system design up front and avoid considerable refactoring, or one can rush to code and re-design it a few times. This might just be my style of thinking. I know a few people that can just write code and build useful applications. Others that do this end up having to throw away lots of code before having something that works well. The key is to find the method that works best for you and use it.

    "We don't need to make all sorts of fancy diagrams, UML charts, story cards, or any of the other things that delay coding."

    Actually, I do need those diagrams. To figure out any system that someone wants me to build, I need to make a high-level sequence diagram and sometimes also an object diagram. These are quick drawings with paper and pencil and help me figure out the system in my head. That's the hard part, actually, as once it's all in designed the implementation is generally simple. Things like interfaces to commercial and open source software, cluster applications, and the like can complicate things, but in general the implementation isn't bad.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://401293]
Approved by Paladin
Front-paged by mattriff
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (8)
As of 2014-12-18 23:58 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (69 votes), past polls