What professional standards do you maintain in a side/pet project?

Question

When working on your own side project or pet project, you are using your professional skills to develop software, but what professional standards to you stick to?

Answers would largely depend on the type of project your working on. A proof of concept or quick demo program might have the worst bit of slapdash cowboy coding. Something so shaky it barely works. A more significant project (100 man / hours+) would be correctly thought out and architected, refactored and maybe even tested?

Do you ever create test plans/unit tests, documentation and design up-front when working on your own creation? Do you follow any Agile philosophy?

Update: What are the gotcha's. Things you wish you had done properly?

Answer 1

First: source-control, even for a small pet project.

Second, lots of static code analysis, to flush out lots of trivial bugs.

The rest depends on the nature of the project.

Answer 2

As you said yourself, it depends on the size of the project. For a small prog that only I will use, I may commit all the seven mortal sins:

1. No Source control
2. No tests
3. No documentation
4. No design up front
5. No seperation between development and production system
6. No keeping track of small configuration tweaks
7. (Whats number 7?)

Just cowboy coding, YEEEEHAW!

But if it will be bigger than say 200 lines of code, or if somebody else will use it, I would always apply the same quality standards that I keep / try to keep / struggle with in my job.

When a carpenter builds his own dining table, would he be any less professional as if he was building it for a client? No, and neither should we.

Answer 3

I use my side projects to learn new technologies, paradigms and patterns.

In my current project I am exploring TDD (Test Driven Development). I am also exploring patterns and language constructs I normally don't use or don't know how to use.

My development environment is setup as if it was a perfect world, which most of the time is better than where I work.

Answer 4

Most of my side projects are just like Charles...to learn new technologies.

The way things generally work is I hack togeather something that sort of works (prototype shall we say), then I check into source control and refactor the bejesus out of it until it's something that i'm happy to utilise or put down (and i'm not talking put down in the lame horse kinda way)

Answer 5

If it's something that can be done in one day and will thereafter be thrown away, I just write it in one go without paying attention to quality. I might not even use source control, although it would be best to use it (now that I've converted to using Git, it should be easier to setup a repository than with SVN, because the repository can reside in the working directory and does not need a separate server). Some examples of such throwaway code: a script for some one-time task, learning a new technology by writing a sample application.

When I write serious side projects, ones that I hope will be used some day, then I keep the quality as high as possible. I write the code test-first using TDD/BDD, all code is under source control (Git), and I keep the code quality as high as possible (e.g. use meaningful names, follow SOLID and other principles). Since I'm the only one working on the project, I don't use project management techniques. At most I keep a track of how many hours I've spent on the project. I publish most of my pet projects as open source, and if the program is large enough, then I write some high-level documentation when the program is finished (low-level documentation == unit tests and code).

Answer 6

Even when doing side projects it is good practice to use professional standards as it makes it more a habit. If you start taking shortcuts in one area they will slowly creep into other more critical areas IMHO. You want to make following good practices secondary, not something you have to remeber to do at certain times.

With that said, side projects may be an opportunity to try out new methodologies and processes, but I would still try and follow some.

What happens if a side project becomes a real production project? Then you have to restart if it was built in a sloppy way.

Answer 7

I use my own projects to develop techniques and learn technologies.

My current project uses hg for source control (because I'm too lazy to type stuff in again after losing it or breaking something, and use both a netbook and a desktop to code on so want a common repository to sync to), TDD (because I'm too lazy to write code that isn't needed to provide features and don't like big debugging sessions), and uses astyle (because I'm too lazy to indent stuff myself) and splint (because I'm too lazy to chase bugs all day). I also keep a workbook with what I'm doing and what I'm thinking of doing, because sometimes I don't touch it for a while, and there's also quite a bit of infrastructure, so it makes sense to write down ideas of where the later stages might be going. I don't do big comment headers describing that the array_get_length(array_ref_t array) function returns the length of the array array. When debugging I use logging rather than printf, mainly because the logging library prints the line the logging function is on - so it's easy to jump to - and you can turn it off with a build flag.

Even at work I don't do big design up front on any project*; instead I plan what I expect to be doing for the next 2-4 weeks down to 2 day slots. Typically in three weeks time the requirements will have drifted anyway, or you're done.

How much of source control, automated testing, automated coding standards checking and design documentation is present in professional projects depends rather on the practises at whoever is employing me. So often my own set-up is more 'professional' in terms of boxes ticked.

'* Typically I'll design/decide the interface by which an message is sent between components up front, then let content, semantics and configuration evolve as required. Then each component is managed as a stand-alone small project, rather than an increment to a big project.

Answer 8

I have an SVN repository just for prototyping new stuff, and it's something that I often go back to so I can review old code. It's on http://www.xp-dev.com, which I'd recommend. I also make a point of never using prototype code in an actual solution, even if it is for my own use.

Official design docs always come after the prototype phase, which makes sense to me, but I'll always write up my findings because my memory isn't as reliable as I'd like. I should use TDD in the actual solutions, but I still need to decide on a framework to use.

Answer 9

Exactly the same professional standards as I maintain in a billable project of similar scale. If they weren't useful, I wouldn't be using them in the first place.

Answer 10

When it's really small application (done under 1 hour), I just bash in the code, quickly modify it in debugger if necessary, and archive it to SVN. But I always, always do proper variable/method/class naming. I think that if I act lazy on this matter, it'll leak into my professional development habits (somebody also mentioned this)

When I think the app can't be made by just bashing and hacking some code , I always sit back and think about preliminary design, create repository in SVN and make it. But I don't make documentation for this, I see it as a waste of time (let's say project size - in order of magnitude of 1000 lines of code)

For long-running pet projects, that I know I'll use on regular basis, I try to do proper design, I strictly comment all necessary code, and try to test it - so my rule of thumb is: if I (or my mates) am going to use my new software regularly, I try to maintain all of professional standards.