13

Possible Duplicate:
Becoming the most efficient one-man team

I am a lone developer. I want to use a development methodology that forces me to use good practice. What would you recommend? I am a C#, ASP.Net developer. Particularly helpful would be to be pointed towards some document templates that I simply fill in for each part of the project lifecycle.

14

You are developing in a team of three developers:

  1. The past you who is a moron
  2. The present you who is average
  3. The future you who's a genius
14
  • On my home projects I use TDD (Test Driven Development), I've found that it helps me keep my focus and the tests help catch design and API problems (that could be caught by co-workers) and helps avoiding regressions issues (I have unit tests).

  • I've discovered that having a source control is also important to track changes and keep the data safe.

7

Even on your own, use version control and an issue tracking system.

That way you can plan, keep track of what you're doing, and can see whats changed over time. Grow your processes as you need to from there.

I'd recommend starting with SVN and TRAC.

2

I recommend using TDD practices:

  1. Start red
  2. Make it green
  3. Refactor

Although MVC framework is not a methodology but its separation of concerns helps you a lot to gain control over your project management.

1

ReadySET provides some software engineering document templates.

IMO, the templates aren't as important as the content. Focus first on documenting interfaces and assumptions. This includes the human interface (aka User Interface or User Experience) as well as software module/class interfaces, and assumptions about system configuration, installation, etc.

1

Do the simplest thing that works

Dont get too caught up with spending ages on design. If your on your own then just do some doodles on the back of an envolope - all you need to do is clarify in your head what the problem is and a rough approach at a solution. After that get coding and see how far you get before you get stuck.

However long you spend designing something there is always the risk that you will overlook something sending you straight back to square 1. In these cases the sooner you get coding the sooner you will find out whether or not your design actually works.

1

When I was working as the only developer in a team and had the business chaps telling me what they wanted and testing, I found Scrum was ideal as it didn't become labourious or act as a barrier. It will also scale when you add to your team later on.

It really is your choice though - so go with something you feel comfortable with.

1

My experience has shown that the most important element in development is: Consistency

Some things that have helped me develop solo;

  1. Document your decisions via a Wiki or some sort of tracking system (Bugnetproject.com is a nice ASPX based ticket tracker)
  2. Try to stick as much as possible to standard coding conventions and best practices
  3. Use frameworks that will both improve your productivity and help keep you consistent (ie; Subsonic, jQuery, Blueprint.css, etc.)
  4. Put as much empasize on the KISS principle as you can
  5. Keep in mind that the first code you write is the first code you will refactor. In other words you will progress, learn and refactor as the project progresses. Document your reasons for refactor and move forward.
0

As you are on your own, which ever method you are happiest with and helps you produce the best output. Without knowing what you are like and how you work best it would be impossible to say which.

0

No methodology will 'force' you to use good development practices. Those are learned and applied by self discipline. I would read some books on development practices like:

Framework Design Guidelines

And some books on Design Practices and Patterns like:

Design Patterns
Head First Design Patterns
Design Patterns in C#

Test Driven Development (like the others mentioned) is a good way to test. Visual Studio has done a good job of building it in and making it easy to unit test your code.

Some kind of Source Control may be warranted depending on how often you are making big changes to your code, you can use the Microsoft Offering called SourceSafe or something like Subversion

0

i think it depends on the complexity and clarity of your project. By clarity i mean: do you know exactly what the goal is, or is it a moving target? Or do you know exactly how you're going to solve the problem? Most of the time it's the former rather than the latter.

i've been a team of one more often than none (rhyming couplet not intended) and the future of the product i'm working on is always nebulous. Over the years i've collected a handful of do's to keep me sane and allow for success down the road:

  • separate your concerns
  • make use of simpler patterns such as: singletons, facades, factories
  • use dependency injection

Following these few principles will give structure to your code that is sharable with others when needed and also flexible enough to be refactored into any type of methodology you want. Of course, these do's also assume a nebulous future and a moving target.

0

You better use a development methodology that fits with your users/employer/supervisor's expectations. Selling as 'Best Practices' is good, but you better be able to defend it when they are demanding a feature be implemented immediatly. They will feel you can go back and do all that documenting, testing, commenting 'stuff' after it is done. Saying, "I have to take twice as long on the project in case we hire another developer." may get you replaced. Then again, if they are too unreasonable, they may be doing you a favor.

0

Start the day by reviewing the code you committed yesterday. Think through design, let it rest for a while and review it. As Eimantas stated it, the future you is a genius, he might have a few comments ;)