I just read this post over at Coding Horror and find myself agreeing with much of it. I always found that writing pseudo code was more of a hindrance to writing proper code in the first place.
It probably makes sense to write pseudo code if you're not going to be doing the actual code yourself. Otherwise, there are a few traps you can fall into - You can get bogged down in putting more detail than necessary in the pseudo code because you're thinking of the actual code that's going to be written and you can also lock yourself into a particular way of thinking that blocks the process of writing the code, because the pseudo code described the functions in such a way that the language being used to write the code doesn't translate well.
I would say writing pseudo code is a particular skill, best left to those who are good at it - They may or may not be coders, or good coders at that. I've found that when writing code, I tended to go straight from the big picture into code, and trying to think about how to get there ended up muddying the waters.
My guess is that for a large project which is going to need long-term maintenance, it makes sense to have someone look at the overview and break it down into pseudo code before any coding is done, otherwise it's probably better to have the coders build up the higher-level documentation as the code is written.
Perhaps the way of thinking that makes most sense to me is that as a writer, you wouldn't write your table of contents first and then the book unless you have a very firm idea of what's going to be in the book. I'm sure most authors would block out their ideas, come up with their characters and motivations, and main plot event and let the story grow from there. A lot of people don't realise the creative input that's needed to write code - It's a bit more than just putting blocks together, no matter how many design patterns have been learned off by heart.
No comments:
Post a Comment