2

I started a project (a Windows based timetable program that helps you stay organised with your subjects and assignments).

The problem is that I'm not sure how I should manage this project and what order to build things. I.e. Should I build all the different interface elements then write the code or should I make an interface, code it, make another interface then code that? So my question is; how do I split up this longish project into small, ordered pieces to complete; and how should I order this?

Kian
  • 305
  • 1
  • 2
  • 8
  • 4
    Could downvoters comment the reason for downvoting so the question can be improved :) – Kian Apr 13 '12 at 17:22
  • 3
    Do you really think anyone could know all the pieces to your project let along tell you what order to build them? – JeffO Apr 13 '12 at 17:53
  • 2
    No, I meant that in a more general way; i.e. I build the main interface, then code that, then build the other parts and code them. I'll update my question now – Kian Apr 13 '12 at 17:54
  • 1
    great question by the way i just set this question as an intern question we ask, about estimation. the accepted answer is something i'd expect back as a response. – krystan honour Apr 13 '12 at 18:50
  • possible duplicate of [Best way to break down overwhelming code into manageable chunks?](http://programmers.stackexchange.com/questions/82582/best-way-to-break-down-overwhelming-code-into-mangeable-chunks) – gnat Sep 02 '13 at 13:35

3 Answers3

8

Obviously, there are multiple ways to split a project into more manageable parts, but the one way that I find both easy and useful is to structure your project around the features that you plan to implement.

First, define your use cases, and make a list of features that you plan to have in your product. Then prioritize the features that the product must have to be marginally usable. Once this set is in place, you could either refactor for things that you learned about the domain that you missed before you started, or prioritize the next set of features, and add them on.

The advantage of this approach is that you do not have to decide on the timeline upfront all at once. Developing new things is inherently unpredictable, so keeping your timeline as open as possible is a welcome thing.

Sergey Kalinichenko
  • 17,393
  • 4
  • 57
  • 73
  • Thank you for the tips! Do you think a kind of onion model would be good - different layers based on their priority? – Kian Apr 13 '12 at 17:56
  • @KianMayne I think that onion models are a better fit for iterations two and above, because they are centered around implementation, rather than features. By that time you usually know pretty well not only *what* you are going to build, but also *how* you are going to build it. When the concept is brand-new, you have a reasonable idea of what's "core", but you tend to discover "outer layers" as you go. Once you start using version zero of your product, the priorities of non-core features will shift, so you should be prepared to it. – Sergey Kalinichenko Apr 13 '12 at 18:15
  • Yeah I see what you mean, good point. This is the exact kind response I needed – Kian Apr 13 '12 at 20:25
7

Everyone organizes a project slightly different, so it's up to you to figure out what works best for your needs. Here's what I do, and hopefully that'll help you out.

  1. Write down EXACTLY what you want your project to accomplish. Think of it like a start-up pitch: clearly define the objectives of this project and how you're going to accomplish them.
  2. Draw out a flow cart for the basic workflow associated with your project. How do you want the user to interact with it? How will things work on the back-end? What may be some common pitfalls that you'll need to look out for? All of these things should be clearly defined in a simple-to-digest way.
  3. Start small and work your way up. This may seem a bit ambiguous, so let me explain: Obviously, a project goes through iterations and "grows" (both in maturity and complexity) over time. So, start with the bare minimum use case, and work your way up from there. For example, I'm developing a small messaging application. I'm not going to dive right into a client/server model where clients send messages to the server. Instead, I started off by writing simple plain-text messages to a file, and having the program parse that file and print out the correct output to STDOUT. When I get that part done, I'll refactor that code to work in a client/server model. Adapt that workflow for your needs, obviously.
  4. Just a note to keep in the back of your head: until your project reaches "production readiness", treat every character of code as expendable. If you think of a "better" way of doing things, do it. Don't keep old code around just because. Even when your project reaches production, don't hesitate to throw out entire files as necessary. Your code can always be made better. Always.

Jokes aside, that's essentially how I organize my projects. I'll follow the basic work flow, writing code for a basic use case, and then work my way up from there, refactoring along the way. Hope that helps!

Z. Charles Dziura
  • 729
  • 1
  • 5
  • 9
  • Another good answer! I wrote myself a messaging program (using the .NET framework; nice and easy) and I started with a console program with a (very) simple client-server model and when I got to a certain stage, after constantly refactoring and rearranging code I ended up completely deleting that original client-server code – Kian Apr 13 '12 at 20:32
1

Sometimes it helps me to just... start. Wherever I can.

Not to say that you shouldn't design; obviously any project needs a design, and a big project probably needs a lot of design. But I think it's easy to get paralyzed by the hugeness of the design; I find there is an awkward phase after figuring out what all the big chunks are but before it is clear to me what or how I should be coding.

At that point, I like to just start writing class declarations. Of course, everything I'm writing is likely to be discarded or dramatically changed, but I feel like I get a much better handle on the project once I start working on it. So I'll spend a couple hours writing code, and then go back to my design and refine it - probably I've thought of another package I'll need, or changed my ideas about the hierarchy I'm building. Then, when my design seems to make sense again and/or I get stuck, I go back to the code. After a few iterations of this, my design is complete and I have a good handle on what needs to be done - and when I know exactly what needs to be done, it's often very clear what order it should be done in.

ejs
  • 11
  • 1