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.

This summer I'd like to develop a number of applications, all of them relatively small, yet risky -they're complex, I'm inexperienced-. I'm gonna work on my own because my classmates or other IT people I know really don't have a genuine interest in programming (I swear!).

Besides from making good code, I'd like to analyze, design and plan everything correctly. Probably applying standard methodologies would be excesive for a single-person project wouldn't it be?

So, what lifecycle and diagrams should I use? In college I've been taught only a very superficial approach to software engineering.

share|improve this question
add comment

3 Answers

up vote 3 down vote accepted

I would recommend to focus on one little project at a time. If they are complex, you probably want to spend some time thinking first, so you can penetrate the problem domain at least to the degree where you have an idea of how to solve the central problem.

Once you have that understanding, and often little sketches are a good way of getting there, then start by implementing the code from the start with unit tests, where each test expresses either a desired result or the ability of the code to handle defective or incomplete input.

For a one man team, most of the standard methodologies are over the top, but the principle can still be applied, albeit at a much smaller scale. I would not recommend spending too much time on beautiful diagrams, hand-drawn sketches will do fine. And since this sounds like you are trying to learn new things about programming, don't worry about lifecycle.

share|improve this answer
add comment

I subscribe to the same idea that Martin Fowler talks about when it comes to diagrams and documentation - essentially only do what makes sense, and use them when they can convey ideas to your customers and team mates - which are both (at this time) YOU.

I've done the same thing - created projects on the side or at home. And the following has helped me, hopefully, take what you like - leave the rest:

1) I still subscribe to the datacentric view of building software. The data (for business apps) is still king. What is the data, and what are the relationships - build an ERD and understand your "business" (for the lack of a better term).

2) Write up a high level list of "Stories" - the things you want your application to do. you can use an individual agile approach and prioritize them and work on them in priority order. First things first, for example - you will need error logging, data plumbing, UI infrastructure, membership services (etc.) before doing your core modules.

3) Layout a good high level design. It doesn't have to be fancy, but put it down on paper and refer back to it occasionally. It can sometimes help you see the forest through the trees when you are working on a fine detail later.

3) Build your core modules. Follow good practices. I won't go into too many details here - you know what they are (e.g. unit testing, separation on concerns, etc)

4) Test it - OK...this is the hard part by yourself. Get a friend or two (my wife is a great tester - bless her heart). Buy them pizza for their time. But you need to have someone who isn't you do this - you know too many of the tricks, and your friends are good testers.

5) Make a plan for deployment or distribution. Marketing and distribution is not normally our cup of tea...so you may want to seek help with this one too.

Enjoy!

share|improve this answer
add comment

Look at an Agile approach. Start by taking small vertical slices of what you want to achieve and working on those in an iterative process (an iteration being a length of time which could be as small as a day or as long as a month). The small the iteration the quicker the feedback on what has been achieved. In all cases what the requirements of a thing are at the start are normally quite different to what they are at the end and any effort you put into diagrams, work flows etc are wasted effort.

Agile process is very subjective and differs from team to team and is much too large to discuss here without losing focus but I do suggest you have a read of one of the many websites dedicated to it.

share|improve this answer
add comment

Your Answer

 
discard

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.