Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm currently working on a project that's about to reach over 5,000 lines of code, but I never really completely thought out the design. What methods should I use to structure and organize my code? Paper and pen? UML diagrams? Something else?

share|improve this question

migrated from Jul 14 '11 at 3:33

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

what language ? – Jarrod Roberson Jul 15 '11 at 12:04
Not pen and paper. Keyboard and monitor. – Tulains Córdova Aug 7 '14 at 20:38
up vote 5 down vote accepted

You probably get about as many different views as there will be answers. But here is my perspective.

For starters, 5000+ lines of code is very very small project. Now, how do you go about designing projects that grow. Firstly, you design your system and not a code. Code is actually secondary to the architecture. Start with supporting minimum current requirements. Put some simplistic drawing of components involved. I personally like UML, but anything visual will be good. Ideally, you want to adhere to good design practices here (interfaces, separation of concerns etc).

Once you support minimal requirements in your design, code it. Again, try to adhere to good coding practices.

After that, iteratively add more functionality as new requirements arise. Ideally you want to update your design as well.

What is important, based on my experience, is not to design your system in anticipation of non existing requirements. Otherwise your project will grow very quickly and will get very complex in a short time. Again - adhere to good practices and starts with concrete current requirements.

share|improve this answer
I believe you mean "perspective," not "prospective." (I can't make an edit because it's less than six characters.) – Maxpm Jul 14 '11 at 3:49
@Maxpm Thanks. Fixed. – Alex Gitelman Jul 14 '11 at 4:11

Flow Diagram, Class Diagram, Use Case Diagram are the must-have diagrams for big projects. Search and select which external libraries you need, and search for any similar open source codes you can use ( to learn & to reduce the time of development ).

I suggest you to buy a whiteboard & some colorful magnets & Post-It. It will help you identifying your tasks.

p.s. 5000+ lines of codes are not "big", though. A CMS / Forum software has way more than 5000+ lines of codes.

share|improve this answer
Serious question: what use is a use-case diagram? The ones I've seen have all been painfully trivial stick-figure & balloon drawings that didn't tell me anything I didn't already know. – Joris Timmermans Jul 14 '11 at 8:28
MadKeithV - like any tool, they are only as good as the person using them. Try to avoid the painfully trivial cases and concentrate on the more complex situations. However, what you find trivial, others in the team may not. A use-case or any other diagram will help ensure everyone is singing from the same hymn sheet. – Gavin Coates Jul 14 '11 at 8:32
@Gavin Coates - I sort of get what you are saying but do you know of any online examples I could take a look at to really sway my opinion on these diagrams? – Joris Timmermans Jul 14 '11 at 8:36

I would create package and class diagrams. In the package diagram I would be interested to group classes and interfaces in a logical manner. I would also like to create inner packages etc...

alt text

But first you need to think what the program should do . You can create usecase diagrams or do it manually. I do it manually with the class diagram because I prefer to get the code immediately and it is easier to swap to package class diagrams later. Using the class diagram gives me my java. If I don't like it then I manually change it. The new code is automatically updated into my diagrams. I have a visual high level updated representation of my code. Really helpful because even if I code I can always take few minutes to look at the way my project is going in a graphical manner. I just drag and drop entities in the right package manually in order to organize it. I think that my code is better using higher level of abstraction package and class diagrams.

alt text

some of my colleagues said my way of working is crap.... but I like it :-)

share|improve this answer

Definitely. I have a small "tablet" dry-erase board to use for this sort of thing, but use whatever you're comfortable with. The important thing is that you can get your thoughts down easily and see the big picture of how everything fits together.

Some people prefer more formal plans, like UML diagrams, but I feel that it's too easy to get caught up micromanaging what each method should look like. Once again, though, use whatever you're comfortable with.

EDIT: You might also be interested in literate programming. The idea is that you can plan it all out and gradually get more specific. For example, you might say that your program consists of:

  1. Getting text from the user
  2. Converting the text into an image
  3. Saving the resulting image to the disk

Then you might refine your idea of converting the text into an image. So that might look like:

  1. Determine the number of lines the text should take up
  2. Pick random colors for the text and background
  3. Process it in a suitable format

Then you might refine the idea of picking random colors, and soon you're just writing regular code.

share|improve this answer

For me, the activity of software development is a series of progressively finer-grained designs to solve a particular problem. When you just have a high-level idea of what you are building, your design might be something very high level, like "there will be a web application that talks to a SQL database and multiple web services" or something like that. Then, as you drill into the details of each piece you get finer-grained in the design. Depending on the complexity of the solution there will be more or fewer iterations of the design effort. The final iteration involves creating the actual code that implements the higher levels of the design.

For me, the difference between architecture and design is minimal, and they are just different iterations of the process I describe above. The line between the two is fuzzy, and different for different people.

There is an art to deciding what level of design detail to go into, for which parts of the application, and at which points in the project lifecycle. For high risk, high complexity projects you may want to have a very detailed design before you ever write a line of code. For smaller projects, you can get away with doing very little up front design and just banging out some code and then seeing what doesn't work and redesigning those areas. There's not just one write answer here. Usually it is somewhere in between those two extremes.

I have a blog post that talks about some of the principles I use when approaching architecture. It might be helpful to you when thinking along these lines. Some of the article is specific to .NET but most of it isn't.

share|improve this answer

I used to ask myself the very same question. Now I just practice test-driven development, and don't worry about it. I don't "plan out" the code at all, except to follow the standards for the chosen architecture. When I start a project, I do have some idea of what is going to be needed, but as development proceeds I try to keep an open mind. By following test-driven development, and continuously refactoring the code, I don't have to "plan out" the code. I just satisfy one test case after another, and the design emerges from the refactoring. This is always a better design than any plans I could have made before coding.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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