First stab at pseudo-code

I’ll be the first one to tell you that I am horrible at planning/designing coding projects.  I think it’s just because I don’t like it at all, and I have a hard time making myself do it.  I love to write code, but the prerequisite work can be such a drag.  Because of this, it probably takes me a lot longer to get work done than it should.  Recently, I’ve been trying to remedy all this.  I’ve been trying to make myself do a bit of planning for the calendar project.

A while back I started reading Code Complete—I don’t get a lot of reading time, so I’m only halfway through, but I’ve learned a LOT in what I’ve already read.  A good chunk of the beginning chapters are about planning and design, and one particular tool really stuck out at me at first: pseudo code.

To be honest, the reason it stuck out to me initially was that I thought it was horribly silly.  I thought, “Why would I want to write fake code, when I could just as easily write the real thing?”  Well, the more experience I gain, the more I realize that I can’t just as easily write the real thing.  Getting the exact syntax of the code correct and finding the optimum way of accomplishing a goal in a particular language can be quite time consuming, and I’ve found that it gets in the way of focusing on the problem itself.  Because of that, I’ve truly begun to see the efficacy of pseudo code.

I’m still experimenting with how I want the syntax and just how much detail to go into, but I can already see how it’s helping me focus on figuring out what needs to go where and what information I need access to in various places.  The latter is where I’ve had the most trouble in the past; too often has a lack of planning led me to paint myself into a corner where I’m missing a crucial piece of data and my design just won’t let me get at it.  In Code Complete, McConnell shows us the gravity of our design mistakes compared to when they are discovered, and I definitely see what he means.

The way I’ve done this project so far seems to have gone well.  Going by the advice of Getting Real, I built a semi-functional mockup of the GUI first.  The idea is that this will let me know exactly what my back-end code needs to do and (more importantly) what it doesn’t need to do.  I haven’t finished reading that book either, but what I’ve read so far has really given me a different perspective on how I approach a project, since it’s written with small development teams in mind.  Is a one man team considered small?  This one’s a free read online, so check it out.

Anyway, with the GUI  mockup done, I started the pseudo code.  The nice thing about pseudo code is that you can lay it out however you want.  You can “code” to any level of detail you feel necessary.  McConnell recommends writing pseudo code to such a level that each line of pseudo code turns into one line of real code; I’m not going near that far in some spots, but every bit that far in others.  We’ll see how it goes!

I realize that pseudo code is only one planning tool among the several that I should be using, but I’m working my way up.  I think the next thing I want to tackle is UML.  I’ve tried using it before, but I found that not really knowing it well ahead of time made it very cumbersome.  If I can ever snag some time to study up on it, I think it’ll be a really great tool as well.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: