Do you know a good way to design (i.e. write down) software with a method based on pseudocode?

I'm new to software design and read some information about UML. My humble class hierarchies are good so far, however, after it gets complex I notice that with "seeing the whole" picture I could have used a different structure for more future extendability. As Python is good to prototyping I'm almost fine with just starting to write, but not quite.

So I tried UML class diagrams, but they don't seem to help me much. The problems I solve there I can trivially do in my head. But I do notice additional design requirements once I start to pseudocode the actual methods.

So if you wanted to design by pseudocode, how would you do it? I believe for me a method which is roughly 1-to-1 with code works best. But most UML software doesn't even show the method's code (as opposed to pictures in e.g. GoF).

Someone claimed UML is for documentation and presentation only and not that great for design? I also get that feeling. I thought pure UML and some simplistic whiteboard sketches were the way to design software until googling I found Envision APDT.

So is agile development something I should look out for or do they randomly call that agile - I thought agile is about schedule only? Or am I designing incorrectly (with UML) - does anyone design by pseudocode? How can I find a good tool for that?

  • 3
    Steve McConnell describes the Pseudocode Programming Process (PPP) in his Book Code Complete 2. The method concentrates on low-level design and implementation, but it might be a good read if that's what you are after.
    – thiton
    Commented Jul 31, 2012 at 8:27

4 Answers 4

 I thought agile is about schedule only?

It is not just planning. Agile software development is more about being a evolutionary development and a time-boxed iterative delivery with adaptive planning which encourages flexible response to changes requested by product owner.

 Or am I designing incorrectly (with UML) - does anyone design by pseudocode? 

In my experience charts are much easier to understand from a client stand perspective. They are visually appealing and many times very colorful and easy to follow. However, it is very hard to maintain charts due to the nature of disconnect with the actual application code. Every time a change is made in the application the developer has to take the time to update all documentation including charts. However, that problem can be easily eliminated once there is a BA in the team or company, who understands client business process well and can manage the UML diagrams.

Tools like UML can make this process easier but only works well with object oriented programming. Pseudo code is much easier for technical teams. The process of creating this code greatly increases the speed of the actual programming language development phase.

There are some other alternatives that you may look as well:

  • Data Flow Diagrams
  • State Diagrams
  • Process Flow Charts

Good references to look: Software Design Tutorials. In addition, i would personally advice to read a good blog on Pseudocode or Code? posted by Coding Horror - my favorite blog to read :)

All in all, there are some trade-offs that you need to consider.

  • 3
    +1 for link to Pseudocode or Code. Just write the damn code. Commented Jul 30, 2012 at 21:49
  • @ElYusubov: Thanks for the explanation. It seems you also imply UML is more for presentation? For the actual design I don't put emphasis on it? In the end you propose 3 diagrams. Can they be made 1-to-1 with code to some extend. I mean on the opposite some things which work in diagram might not work with code - that I want to avoid.
    – Gere
    Commented Jul 31, 2012 at 8:22
  • @Gerenuk, data flow diagrams can be made 1-to-1 with code flow. However, diagrams are generally used to see high level design and interaction between components/modules/use cases.
    – Yusubov
    Commented Jul 31, 2012 at 8:26

When programming in assembly language, writing pseudo-code makes a lot of sense. The algorithm could be verified before expending the effort to manually translate it to assembly language and then debug the translation. It still made some sense for first-generation compiled languages like FORTRAN IV, where the only control construct was GOTO, all variables (except formal arguments) were global, and variable names were limited to six characters.

Today we do very little programming in assembly language, and I see little value in writing pseudo-code instead of just writing code. In a decent language, the actual code will follow the pseudo-code almost word for word, and the pseudo-code is just a waste of time.

However, I don't start coding at the bottom. I follow TDD and start with a test. Then I start coding at the top, and gradually work my down to the bottom as needed to get the tests to pass.

The alternative to pseudo-code is not writing 1000 lines of low-level classes. Instead start at the top, calling the ideal but non-existent API for your domain. Then build the API.

  • When I just start coding, sometimes later I notice that design-wise I could have factored out some code. While refactoring is OK, it still could have avoided it if I had seen on overview of all the code first and used some creativity. A graphical pseudocode view could present everything in one condensed graph. Is my mistake somewhere else?
    – Gere
    Commented Jul 31, 2012 at 8:31
  • 2
    Your mistake is in the belief that refactoring code is somehow more work than refactoring pseudo-code. With a modern IDE it is easier and faster to write actual code than to mess around with pseudo-code either on paper on in a plain text editor. Commented Jul 31, 2012 at 15:32

I find class diagrams to be barely worth the effort, even when you skip listing all the methods and simply show the inheritance hierarchy. Sequence diagrams are good, but feel awkward when I'm drawing them (probably just me).

I find data flow diagrams and structure charts to be more useful (although structure charts are commonly associated with BDUF and are therefore out of favor at the moment). DFDs are especially useful for functional decomposition. Each "bubble" in a DFD can be broken down into its own DFD until you get to whatever level of detail you want.


I think graphical tools are better than pseudocoding, but UML is simply so much overcomplicated that it combines the bad in those methods :-)

To be a bit more clear: I think programming is mostly a way to analyze a certain problem, separate it to smaller components and their interaction. This is "a journey, not a destination", you constantly improve your knowledge about the problem, so the graph of components is changing: layers appear and fade away, functions and data items move up and down, etc.

The natural tool to follow this process is a sketchboard, as simple as possible, but enough complex to help quick understanding (same colors, shapes, arrows for the same logical meaning). I have not found the silver bullet, and perhaps I will write my own one day, but now I use gliffy; combined with the zooming feature of prezi it would almost be perfect.

Why not pseudocoding? Pseudocoding is one step forward to implementation, a "serialized form of the component graph", when you yet shape your ideas. Not good, limits your head. In my experience I found that the later I start coding, the less code I have to throw away...

But perhaps this is because I have written all those thrown out codes, so I don't have to write them now, the experience I gained from them is with me when designing the system? Well, I have to modify the statement.

If you are lost with your graph, and see many equivalent possible solutions, do go to pseudocode, or even do write that code with mock objects - in Java, that is almost no difference. See the code, feel the structure and usability of those components, it will help you fixing your graph and make decisions. But this works ONLY if you are ready to throw away that code if you feel it is bad. I think this is the advantage of pseudocode: the less temptation for keeping it when it works, but it is wrong in structure (and as always, you don't have enough time). :-)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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