8

I heard many people saying that when developing algorithms you should first use pen and paper, flowcharts and what not, so that you can focus on the algorithm itself, not worrying about the implementation of said algorithm (i.e., you deal with one problem at a time).

However, most of the time I find it easier to actually develop my algorithm on the fly. That is, I think a bit about the problem until I know the general direction to take, and then I start writing code and making changes until the algorithm emerges and works.

Is this a bad habit that I should try to change?

8 Answers 8

11

Some algorithmic development can require a lot of trial-and-error testing and tuning, as one can find that the assumptions that would go into a strictly paper design turn out not be accurate enough when given real data and performance constraints.

Maybe iteration (think-code-test-think-code-test...), rather than just an either-or choice for the optimal "habit".

0
3

There is also a middle way, that I usually use. Not thinking too much in advance, and not getting lost into the details of my code ...

TDD (Test driven development) lets you think a bit, then make it work ; then think a little more about what you need, then make it work, having the security net that your previous Use Case keeps working at all times... The steps are:

  1. Write a test (ie a Use Case).
  2. Watch it fail, make the failure understandable.
  3. Write the code.
  4. Refactor the code and the test.
2

This depends on your thinking habits and algorithm complexity.

Pen and paper offer "free form" thinking without a compiler shouting at each character you type.

Some of us who use pen and paper, take the time to adjust loop limits, try different values, etc.

So, I guess that writing the code directly encouraging test-first approach where as the pen and paper promotes think-first approach. It is definite that if the task is trivial, you can code it on the fly (if you are experienced enough) but complex algorithms would probably need a different development approach.

Diagrams help in some cases, but this requires that you be familiar with them and have used them before.

2
  • That is more or less why I asked. I think that the "think-first" approach will make you a better programmer in the long term. Thanks for the answer. Aug 29, 2011 at 20:49
  • Yes, but are you that kind of guy? Some people develop code iteratively by trial and faliure and won't learn any other way.
    – NoChance
    Aug 29, 2011 at 20:51
2

I think yours is the more common approach. If the algorithm is especially intricate or difficult it can be tough to both figure out the algorithm and implement at once, but in general I doubt it helps most people.

But I wouldn't, say, invent rules for a grammer and implement a parser for it without writing the rules out on paper (or maybe with some special tool I don't have) first, or implement a B-Tree without pseudo-code available.

I wouldn't say you have a bad habit unless it's doing you some harm, and I think you would notice if it were.

1
  • Gotcha, and yeah I think that for larger/more complex projects I do tend to spend more time on paper. Aug 29, 2011 at 20:48
2

Who are these "many people?" And are they programming for a living? What you are doing is exactly what most programmers do, at least most that I have known. There's little use for paper when it's faster to type, and little use for pseudo-code when programming in a high-level language. Occasionally I do use pen and paper to visualize a tricky algorithm (e.g. rotating a tree), but mostly I start with high-level code and gradually fill in the blanks.

Like KLE, I think this works better following test-driven development. Assuming you are going to write tests anyway, you may as well write them first.

0

you can create a design while making the stub classes, methods and tests but you can get bogged down while creating the details

for the really complex stuff (compilers and such) a pen and paper design (or at least on a design tool of sorts) will help to keep you on track and the eye on the whole picture and avoid bad design choices and even let you choose certain design patterns from the start

but ultimately it depends on how well you can keep seeing the big picture

0

I'd recommend sketching the general directions (the "pen & paper" phase) before jumping to implementation to save time by getting the most obvious requirements/constraints out of the way.

Then you can finetune it on the way given you can never guess everything at the start because further contraints may/will appear later in development, for various reasons.

That way you know where you're going but you can still adapt to changes.

0

1. The amount of preparation needed is typically proportional to the complexity of what you are doing. It makes no sense to pen&paper 2 full days for an algorithm that is used once in a quarter, runs one hour singlethreaded on one machine only. It makes sense to pen&paper three man-weeks (if necessary) to design the new high-performance flux compensator module which will be able to process half a million requests per hour and has to run 24/7/365 without downtime.

2. You can tell if it's a bad habit within 30 seconds if you look at what solutions you are coding. You asked if it is a good or a bad habit. Well, that depends on you. If you are a slow learner at the beginning of your programming career, it is probably a good idea to pen&paper to full detail everything. If you got some years of experience, it will be enough to just think it through for 5 minutes and then just do it. Of course still with respect to 1. above.

Bottom line

Only your code tells the thruth whether you need more or less pen&paper. Don't let anyone else dictate that to you, but find it out on your own. That keeps you learning.

Disclaimer: This may not be what's called mainstream thinking and common sense. That's ok. Just set a bookmark and read it again in five years or so.

0

Not the answer you're looking for? Browse other questions tagged or ask your own question.