Do you map out a program before writing?

Coldblackice

[H]ard|Gawd
Joined
Aug 14, 2010
Messages
1,152
I'm wonder if (and how) [H] programmers go about mapping/laying out a program.

Do you just open up the editor and start coding? Do you UML it? Mindmap? Bullet-pointed notepad?

I don't really have any routine or procedure for this. I just open up the editor, and then list a bunch of bulletpoints in the header of things to do, questions to resolve, things to research, etc.

I feel that it's a bit "sloppy" of me, though, and I'm wondering if it'd help better/refine me as a programmer if I took the extra step(s) of getting in the habit of visually mapping out what I'll be working on.

I found a Stack Exchange (Programmers) question where a couple diagramming sites were suggested, such as

http://www.balsamiq.com/
http://yuml.me/


Thoughts? Suggestions? (on the overall topic, not just those sites above)
 
Generally I just write down in bullets the questions or problems I'm trying to solve. If something ends up taking more work than I thought I might make a seperate set of bullets for what needs to be done. Overall though it's a lot like you in that I just dive in and start. It might be sloppy but I feel like after you spend a bit starting to implement everything you get a better feel for what actually needs to be done for your program.
 
I've usually made diagrams, of varying degrees, for my projects. Lately it seems like I've been doing more with whiteboards or pen+paper than Visio or more advanced stuff.

If the mockup is UI and for non-technical people, then I try to use Balsamiq. This SO post gave a good summary for presenting UI mockups to non-technical people:
The more functional it looks, the more functional non-technical people will think it is.
 
I love to use pen/paper and whiteboards for it. Once the scope has been more or less set in stone I use Visio to polish it up if they need something formal. Things can change a lot in the project brainstorming phase so it's much easier to grab a ream of paper and go from there. I draw out the system and do bullet points for things they want accomplished.
 
I tend to just dive right in, perhaps it's not the best way so I'm curious to see other responses. I will usually map it out in my head to some extent, at least the general structure of the app, then go from there. As I progress I map out more individual stuff in my head then continue. I normally start writing all the blank functions then fill them in with actual code once I've established that this structure will work.
 
I recently started using rspec to drive my development. It's a Ruby tool but I'm sure there are similar alternatives in other languages. Basically, the first thing you do is write down what you want to do with a unit test...

Code:
describe Address
  it 'may be geocoded'
    a = Address.new  street_line_1: '1234 My Street',
                          municipality: 'Chicago', 
                          postal_code: '12345',
                          administrative_area: 'Illinois'

    a.coordinates.should be_nil
    a.geocode.should be_instance_of(Geocoder)
    a.coordinates.should eq([-227,2149])
    a.administrative_area.should eq('Illinois')
  end
end

...Not only you are ending up with a pseudo-like code of what you want to do, but it also doubles as a unit test. It's great.

I know this isn't a substitute for a UML diagram or something similar, but it sure makes things easier to clarify how individual parts of a program should behave. It's definitely one of the things that should be done before any kind of programming.
 
It depends on the complexity of what I'm about to write. I do mostly shell (bash) and perl and some PHP for work.

For most of the shell scripting utils I end up writing I usually either whiteboard it really quick and then snapshot it with my ipad's camera or just start writing them.

I have templates that I've written that are the basic skeleton of the scripts that I write since we re-use certain conventions over and over...but sometimes the logic can get complicated.

For the PHP code that I do, i usually template what I want the page to look like etc and that's my guide, initially at least. If I have to write anything more than a basic class I'll usually UML it out.
 
for back-end work that I usually do, I often have to talk it out extensively. Then I draw the interface requirements out on a whiteboard. I start by thinking about the expected behavior at various levels; I like to discuss corner-case scenarios because it helps me define the behavior in between.
I've always likened it to math curves: define the critical points and inflections then figure out what happens between them.

From there, I do more detailed requirements and "gotchas" on paper at my desk.

It's easier for me to think about "real world utility" using physical media and drawing arrows and such on paper... not sure why.
 
It's a constant cycle of designing and coding.

You'll likely be unsuccessful if you try to design your entire application with full completeness and accuracy before coding. You'll be equally unsuccessful if you try to write your entire application without ever taking time to think about and lay out design.

The only real exception I can think of is a small and trivial application, although I'd recommend spacing out ample design time and engaging in discussions about structure. I've recently inherited ownership of a tool here at work that's grown far beyond its original use and is starting to hit its limits because it wasn't designed in a way to accommodate this many users.

At the office, the extent of UML we use in our team boils down to some sketches on whiteboards, pieces of paper, and/or napkins if we're doing it over lunch. Often times we just snap a picture of it with our smartphones and load them to our computer. Most of the PMs I've worked for in the past are fine with that so long as we have a working class diagram and documented use cases, but we have one or two that like to see the interaction diagrams we sketch out become fleshed out into true software-drawn UML diagrams.
 
Last edited:
It really depends in how big the project is and how it is for.

  • I'm a big fan of Inspiration mind mapping software for requirements specifications. It's a fairly basic package but it is great for quickly modelling the specs right down to detailed use cases.
  • I just use the SQL Server diagramming tool for the data requirements, it's fast and it creates the database for free!
  • I haven't found a good UML diagramming tool which doesn't distract in trying to make everything look pretty. Visual studio is getting pretty good at generating diagrams, but this is after you've wrote a significant part of the software.
  • User interfaces: paper and pencil! (waiting for the Surface pro).
 
I'll generally have the upper level classes mapped out. The rest will be created when I realize I'm copy/pasting the same blocks of code a lot. Then half will be removed during the first code-refactor.

UML and detail design is great, right up to the first code refactor.
 
Unless it's a major revision of a current application I just start coding. Otherwise diagrams and uml diagrams i use.

If it's a new project that isn't a no brainer i do the same with diagrams and uml diagrams. Hardest part usually is making a good connection with who wants the program and what they want done so after you show off the first draft it's not drastically changed.
 
I like doing mind map style planning but I don't use any real tools. I just open a huge image in an image editor and draw it with the mouse. I found most tools for this are way to rigid and you spend more time with the tool than your ideas.

Then I just start coding, getting bits and pieces working and then refactor. I try to do this in very small stages (like 20-30 lines of code at most) so it never gets to be a giant mess that needs to be re-written.

I only discovered mind maps a few months ago. Somehow I missed the train on them over the years. It's useful to discover how your application will work and how things will work together.
 
I use MySQL workbench to map out my databases usually(even when not using mysql as a backend).

As far as process flow... In college I used Nassi-Shneiderman charts and now I just draw out the process on paper or my white board usually... and then begin mockups.

I can honestly say all the programs I've used before to diagram my process flows before have been more of a hindrance than a useful tool. I always fall back to pen+paper and dry erase board.
 
It's a constant cycle of designing and coding.

You'll likely be unsuccessful if you try to design your entire application with full completeness and accuracy before coding. You'll be equally unsuccessful if you try to write your entire application without ever taking time to think about and lay out design.

I agree, ask yourself what is needed, design a little, code a little, get others' opinions, refine designs, code more, perform formal demo, get feedback, wrap up coding and switch to polishing.
 
Back
Top