Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm not sure this question belongs here, it's not so much I problem I'm having with programming but rather a problem of what to do before I start programming.

I want a visual representation of what variables I need and what classes have what methods.I know there is UML but I'm not sure if that is the best way, so what do you guys use before you start programming, which method?

I don't want to start a flamewar about what is better just what are several approaches?

share|improve this question

migrated from stackoverflow.com Mar 3 '11 at 7:10

This question came from our site for professional and enthusiast programmers.

closed as not constructive by Mark Trapp Dec 17 '11 at 6:17

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

Play "Eye of the Tiger". –  NickC Mar 4 '11 at 20:33
I believe this is a good adept for a community wiki. –  Michal Mau Mar 5 '11 at 10:26

10 Answers 10

Whiteboard. If I can explain what I want to do (and why) to a colleague on a whiteboard, I usually end up with a cleaner solution as well, and sometimes end-up copying the key parts of the whiteboard into my notebook as an improvement to whatever was written there already.

share|improve this answer
+1, although I usually start by trying to explain it to myself. –  Matt Ellen Mar 3 '11 at 9:42
Whiteboards. I still can't imagine how I ever managed without them. –  Filip Dupanović Mar 3 '11 at 11:46

I usually start with a redbull. Then I go over ideas on the drive into work. Sometimes I ignore my wife because my mind is still thinking about it later, over dinner. Maybe scribble out some design notes. Then I prototype quickly and show to some colleagues.

share|improve this answer
+1 for quick prototyping - running prototype code is more useful than any design –  Erik Romijn Mar 3 '11 at 8:29
Quick prototyping is part of the design imho, it's one of the tools to validate if the current design fits –  wildpeaks Mar 4 '11 at 23:45

Personally, I find most graphical representations of code to be unnecessary. Whenever possible, I start with a unit test. Then I write code to make the test pass. Then I write another unit test...

It sounds like you're trying to make it right, then make it work. I would turn that around and instead of planning in terms of variables, classes, and methods, I would focus on the desired result, achieve that result, and then make sure the code is "right" by whatever standards you, your project, or your employer hold dear.

share|improve this answer
This can work for some projects, but most of my code these days is web-facing and project-specific, and by the time I am ready to write the first line of code, the visual design work has been set mostly in stone. –  markh Mar 4 '11 at 20:53

I usually start with a trip to the kitchen to get a drink :)

share|improve this answer
yup, can't do anything without getting a cup of tea first! –  RYFN Mar 3 '11 at 9:45
I agree, a nice brew first! –  TeaDrinkingGeek Mar 3 '11 at 14:22
  1. Think.
  2. Write a very raw prototype.
  3. Think again.
  4. Write proper code.
  5. Explain it to someone else.
  6. If I felt stupid during step 5, rewrite it.

This is of course for smaller pieces of functionality. Bigger ones need to be broken down first, which I tend to do in my head first then write a nice document out of it.

share|improve this answer
+1 for points 5 and 6. More developers should do that. –  Mason Wheeler Mar 4 '11 at 22:35

I'm a minimalist and I don't use UML or anything of the like, so I'd probably just sit down with a sheet of paper for each class and write out the necessary fields and methods. If there was inheritance involved, I'd arrange the papers in a hierarchy according to their inheritance. If you're looking for something more visual, try using different colors for fields and methods or different shapes for different storage classes and levels of access (e.g. if you're using Java or C++ underline static stuff, put a circle around public stuff). You can also draw lines or arrows between fields and methods to indicate their relationships to each other.

When all that's done, you can put the inheritance diagram up on the wall and pull down each class's paper as you work on it. I'm not sure if that's a formal technique or if there's a standard way to do such things, but that's my $.02.

share|improve this answer

I usually start by creating interfaces and classes without implementing them yet. Depends on the language, but I find it useful if you can throw not implemented exceptions all over the place. Then, once you have the whole thing written down with valid syntax and structure that compiles, you can start implementing features one at a time. This way you get some help by the compiler about what is wrong with the code, what you should do next, etc. Beats writing things on paper most of the time, cause you get more feedback in the process.

share|improve this answer
Sounds like you're half-way to TDD. One thing I would caution about is that it can be very tempting to think "oh, I should stub out this method, and this class, and extract that interface..." and end up with a much larger, more convoluted class hierarchy than you need. Sometimes, YAGNI. –  Isaac Truett Mar 2 '11 at 18:33

I agree with hotpaw2, and often start out at the whiteboard. Specifically, I tend to draw lots of boxes, arrows and lines, interspersed with some acronyms and the occasional key word. This is not meant to make a detailed design, or even necessarily to describe my ideas to a colleague, but to get an idea of what action flows are relevant, and what pieces of information are needed at each step, at a more detailed level than the specification from the stakeholder. Many times, this involves several rounds of erasing and drawing, and sometimes going it over with a colleague, but towards the end I have an idea of what the finished code actually needs to do.

Given this, it's usually pretty clear what data structures are useful. So I need a few bits of configuration data from somewhere (anywhere)? That's a Configuration class holding those right there, and maybe a ConfigurationProvider or similar to populate it. Corresponding interfaces to aid testing, even if I don't have the time to write unit tests up front. Customer details? It's the same thing. Once I am mostly happy with how it has all turned out in theory, I might copy it to more permanent storage, usually in UML or a UML-esque notation in my notebook (if it is only for my own benefit, no need to get too elaborate - at my current job, class diagrams are rarely called for, but action and component diagrams are very useful). For a project I am working on now, one major part of the design took shape on the whiteboard long before I started implementing it, based on a rather vague statement of intent in the specification.

Only once I have the data structures and action flows down do I start thinking in terms of the concrete implementation: methods, entry points, specific data flows, and so on. Usually it's not before then that I even open up an IDE.

share|improve this answer

I prefer having time (a day or more) to think about a problem before I start working on a solution, creative ideas need time. I tend to just do this in thought without much externalization, although I sometimes make some lists of entities, use scenarios and data elements.

Having a conversation or brainstorm with a fellow programmer can be very valuable. Other then that I tend to design and discover while I code.

share|improve this answer

Before I start the implementation, I write a test. If I don't know enough to write a test, then I go talk to the customer. Usually the first test provides no input, and merely checks to ensure that no output is produced, or that the expected error is emitted. After defining the test, I then create the minimal software to pass the test, including the build and installation scripts. Then I write another test.

share|improve this answer

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