Best Development Methodology for One Person?

I spend a lot of time working on projects in which I am the sole developer, project manager, designer, QT person (Yes, I know… Bad!), and sometimes I’m even the client.

I’ve tried just about everything for planning projects and managing myself, from just sitting and working freestyle until the project is done however long it takes, to a single-person version of scrum in which I held a progress meeting with myself over a one-man burn down chart every morning (not kidding).

For those of you who spend much time working alone, what is the best way to organize yourself, manage large (for one person) projects, and keep productivity as high as possible?

Keeping a clear list of your goals is vital. It’s easy for feature creep to take over a self-managed project. The TDD “it’s done when it works” approach is helpful as well. This prevents you from becoming a perfectionist.

One thing that really helps me is to imagine what another engineer or a project manager would say in any given situation. Often I’m able to “shame myself” out of bad code, or get back on track if the schedule is slipping.

Here you go… http://xp.c2.com/ExtremeProgrammingForOne.html

XP scales down nicely since it is optimal for small focussed teams..

You can create a spreadsheet of feature requests, prioritize them & pick the top-most one.
define the acceptance criteria (what done looks like) and code it up into a executable test
Next define engineering tasks to get to done
Write unit tests, do the simplest thing (YAGNI) and refactor all the time. The goal is to make the outer acceptance test pass
Timebox each session. For effective time-management, you could also look at the Pomodoro technique.
Use version control & Setup a CI server / a batch file to create a install or zip of your software
Demo frequently. Route the feedback into the original spreadsheet and reprioritize

The only thing that you couldn’t do in a team of one is PairProgramming.

If you are working solo. Here are the advices:

Do as little low-level work as possible. Use as much library and tools as you possibly can including things you think you can easily code (don’t do it, just use the library).
Take the top-down approach. Only code things that you really need.
When you see a problem in abstract term, search on google and use research papers from academic community which has been proved already. You only need to code their algorithm.
Design your system so that you can freely change things as much as possible. (including copy and paste some code from here to there). The purpose is to save you time when you realize you made a mistake. Try to minimize the amount of work you have to throw away when you make a mistake. A piece of code that has to be thrown away (instead of copy-paste from here and there) is the equivalence of time you lost writing that code.
Have lot of automated tests so you can regularly do regression tests each time you make a change
Separate the responsibilities of your design (i.e. reduce coupling). Make things as modular as possible
Use a debugger to debug and use binary search to find defect.
Constantly refactor your code to reduce (explicit) coupling and public methods exposure (implicit coupling).
Nothing really. This is here just in case I can come up with something new 😛

Code reviews.

These are particularly useful as you’ll be explaining the code to someone who hasn’t worked on the same project so they won’t have any of your assumptions about how it should work.

They’ll also have the added benefit of sharing knowledge around the company so when someone else has to work on the project (due to people being busy elsewhere, off sick, having resigned or been fired) they’ll not have to start from scratch.

I’ve rolled my own version of agile that relies on stories, heavy customer interaction, frequent releases, and test-driven development. I use a wiki to track stories, get the customer involved as much as possible in writing them, and have the customer work with me to prioritize and organize into releases. I use TDD to drive the design and implement. I set up a QA server where the customer can try out frequent releases (sometimes daily as new features are developed) so that I get feedback quickly. I rarely go more than 3 iterations without a release to QA. Customer gets to decide when the QA version has enough features to go live — and if no more features off the list need to be developed.

At my company our group all works on the same project, but on relatively independent slices of it. One thing we do a lot around here is when something you’re doing seems a little tricky, or you’re at a fork in the road with more than one way to implement something, you grab someone else and discuss the pros and cons before you proceed. If you wait until you consider your code finished to do a review, you’ve usually already invested too much time to consider major architectural changes, although certainly a lot of defects are uncovered in code reviews.

Also, I realize Test Driven Development is a little buzzword saturated lately, but it can be a big help for solo developers because it provides a quality check as you go, and when tests become difficult to write you know you probably need some restructuring of your code. It also helps later maintainers to not accidentally break the code in hard to detect ways.

I suggest you the following:

Test-Driven development
Eavy use of “TODO: note here” in your code when you see something you are not able to do immediately, and come back to them when you have time instead to stay on facebook waiting for your client to call back
Write your code as your client will buy it looking at the code not at only the result, imagine your client as the chairman for a code review.
Fill your code of asserts

i wish i could say i was able to practice what i preach 100% of the time, but BDD seems to be a good approach to take in your situation:

Here’s a link with more info: http://en.wikipedia.org/wiki/Behavior_driven_development

I’m in a very similar boat. I try to follow agile principles (as well as I understand them) as much as possible. I’m probably not doing things “correctly”, but I’ve had great success on my projects by trying to follow agile principles. It takes an enormous amount of discipline, since there’s no team to make sure you don’t just start taking shortcuts.

I find that using code formatting tools such as ReSharper ensure that, at least visually, the code is easy to pick up for other developers.

In terms of actual methodologies, it’s difficult for a single developer to stick with any particular one. I am a consultant who generally works alone, and I find it the easiest for both myself and the client to use an agile process. I typically try to get my clients to directly enter their requirements into a tool such as Trac (or I will, on their behalf). This not only helps other developers identify the purpose of code, but also yourself 3 months down the line!

philosophy: XP/TDD + GTD

general outline:

interview stakeholders
screen mockups, walkthroughs, paper prototypes (as necessary)
feature/story brainstorming (with and without stakeholders)
test-case brainstorming (with and without stakeholders)
overall design/architecture think-time (as necessary)
iteration planning (with stakeholders)
iterations
process review, training, maintenance planning, etc (as necessary)

Any appropriate methodology will help – irrespective of the number of people on the project. So pick one at at time and see how you can apply and map to your domain, and measure their successes.

Perhaps more interesting is to ask, what methodologies not to throw away because there is only 1 person working on the project.

And the key one that stands out to me is Source Control ( Yes that is a tool, but it is part of your work flow, so also a process ). People might be tempted to give this is pass since they “don’t need to support multiple people editing the code at the same time”.

Ironically I find that a distribute version control solution like GIT is better for an individual that something like SVN.

If it’s throw away code might be able to be a little loosey-goosey with methodologies, but anything important and I’d say your way of treating it as team project with one person is very nice and disciplined.

Write your code for the next guy to read, not you…be nice to him/her. Even the “throw away” code stays around forever.

Agile

features, stories, and test cases are far more instructive than more formal documentation, and a set of working tests is better at demonstrating how to use something or how something works than any amount of dead trees

It is also easier to hand off work in between iterations.

As a consultant my self, I would suggest that you find a way for there always to be at least two developers on any assignment.

I agree with going agile, and on leaving an agile trace of stories and tests that others can follow, but I don’t believe that or any other process or methodology will stick while people are working in solo.

I think Code reviews are a good start but I like it when its made informal and fun, like doing a Pair code review or pair programming in order to tackle a certain issue/problem or some enhancement (e.g. changing legacy code to meet new coding standards). At times two sets of eyes is better than one and its also fun, I feel that sharing and discussing seems more open. You could also have like formal/informal lunch and discuss sessions to talk about what you did individually or as a group e.g. mention about a new pattern you used or new technologies how a problem was solved?

Filed under: softwareengineering - @ 02:17

Thẻ: development-methodologies, solo-development

Thiết kế website giá rẻ

Danh mục

Best Development Methodology for One Person?

Agile