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.

I've been the lonely programmer in my work for quite a long time. Usually I've read articles and posts about

  • Version Control Systems
  • Continuous Integration/Delivery
  • Development methodologies: Scrum, Waterfall, V-Model, Agile, XP, etc.
  • Software Project Management

But almost all of them seem to be focused on TEAMS. I'm not a team, so what would be the absolutely minimum set of practices for just one programmer? Consider the following conditions:

  • I don't have conflicts with other's people code.
  • I don't need to maintain files/directory trees, my developement environment cares about versioning by itself (image-based development).
  • There are no formal requirements, my users don't know what they want and they're are ok with that.
  • The only one which could be interested in delivering a release or documentation it's me, basically customer want RESULTS and doesn't care about software methodologies, etc

My view is that I don't want to spend (too much) time and energy in anything not directly related with the customer requirements. Any recommendations?

share|improve this question
    
How many releases do you have in the wild that you need to do bug fixes for? –  user1249 Sep 3 '11 at 10:03
    

5 Answers 5

up vote 16 down vote accepted

There's no right answer to this question because it depends on each person. If you use an iPad to do all your dev work and your clients are happy with you, you have no reason to change at all.

If, however, I were in your position, I would strongly enforce the following:

  • A version control system - While you may think an image-based development system does the job regarding regular backups and whatnot, you have zero wriggle room for experimental features where one would normally use a branch. You also have no way to retaining an important version of the project (tagging). If you ever expand to beyond just yourself, the developers that join will will think they're in hell.
  • Agile - This method is extremely applicable for clients who don't know what they want. Sooner or later, they'll realise they don't want to be spending money to chase their tail - they'll want to see progress.
  • Project management tool - This is a must. It's very formidable to be able to retain everything in your head, but you don't have to. Being disciplined and using a project management tool (e.g. Redmine) will allow you to separate your tasks and give you an easy-to-browse history of your work. It'll be very important for when you start charging per hour.
share|improve this answer
    
+2 for the Agile and Project Management. However, for experimental features I usually fork a virtual-image (which would be equivalent as branching) and eventually open another instance of my environment. Thanks for your good reply. –  user869097 Aug 22 '11 at 11:42

I'll just answer one, version control is massively important for any project and not just team ones. It takes a very small amount of extra time when you're using it but it provides a rich history for you to fall back on, it's not a silver bullet but it's certainly nice to be able to revert back to a working copy if that really experimental feature has broken most of the application.

share|improve this answer

Version control is an absolute must for any programmer even a lone one. It means you can recover simply and quickly from deleted files and complex changes that are just wrong.

Basically it saves you from the stupid shit you do when you go to work hung over.

share|improve this answer
1  
That's not the only benefit. One of the main benefits is being able to reproduce an earlier version of the software. And that is useful when trying to reproduce a problem and/or determining when a problem was introduced. –  Marjan Venema Aug 22 '11 at 10:34
2  
Plus 1 because it's saved my hungover brain so, so many times. –  Nicholas Smith Aug 22 '11 at 10:45
1  
Also, branches. Many times I had this situation where I started a breaking change, and got a call to make a release with replaced graphics or other minor stuff. With branches, it was extremely easy to do, just switched to my master branch and built the software. Without it? I would have pulled my hair out to either finish the breaking change or revert it to be able to produce a stable release. –  Tamás Szelei Aug 22 '11 at 10:46
1  
Presuming you write useful check-in comments, it also gives you a great way of going back in time to answer the question "What was I thinking when I wrote this pile of junk?" –  Ned Aug 22 '11 at 11:12
1  
@user869097, part of the intention of the SE sites is that questions and answers be useful for more than just the original question asker. While your unusual requirements may make version control impractical (and I must say I'm not entirely convinced, because your branching methodology doesn't seem to allow merges), the majority of single developers who aren't using version control should be. –  Peter Taylor Sep 3 '11 at 8:36

Version control is absolute must. Not only because of the keeping the source ok, but because of the source archaeology. A year from being able to check how a class or procedure evolved could save a lot of pain if you try to "fix" some piece of weird code.

For methodologies - I strongly recommend the programmers manifesto. It usually gives great results in small teams because of zero overhead and not having to keep in your head how the bunch of J2EE portlet-enabled JSR-compliant MVC role-based CMS web service application container frameworks work.

share|improve this answer

As others say, version control or source code management is extremely important. Use a DVCS, and learn everything about it. It doesn't really matter which one it is, though it might benefit you if you chose a popular one: git or mercurial.

Another thing I didn't see mentioned, is a one-step build script. This is not straight-up continuous integration (that phrase is prone to BS in my opinion), but a very useful tool. Whenever you need to make an emergency update, you can just run the script and be done with it. When approaching the end of the project, it also happens that several builds are required per day. My experience is that it pays off greatly, even if the build process is not too complicated. You can even add ftp uploading capabilities, reports in e-mail, running unit tests, building installers, signing etc. Having the script written from the start it's easy to maintain and expand with more steps as the project progresses.

share|improve this answer

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.