I guess I could ask the reverse of that question, but I think in most cases our work software is held up to higher standards than our software at home. At least I assume so anyway...

What I'm interested in finding out is how many developers write software at home to the same level of quality that is expected at work? Before you answer, ponder these questions:

  • Do you have a source code repository?
  • Do you use it?
  • Do you still check-in many times while coding (like hopefully you do at work), or do you wait and do one massive check-in before you go to bed?
  • Do you have a task management system?
  • Do you have a bug tracking system?
  • Do you assign bugs a severity level?
  • Do you set milestones?
  • Do you hold yourself to them?
  • Do you use the same types of patterns?
  • Do you apply a separation of concerns?
  • Do you write clean code at home, or is it a mess just to get it done?
  • Do you write tests?
  • Do you run them?
  • Do you have a build server?
  • Do you use it?
  • Do you practice continuous integration?

Assuming all of these things are happening at your work, how many of them do you practice at home? If you answered no to any of these questions, why? It's a serious question because I've found that the better developers usually do this stuff at home. Not always but in most cases I find this to be true.

You see, the better developers get that in order to be great, they must move from being a coder to being a developer (I'm aware of the book and admit I haven't read it). Developing high quality software is so much more than slinging code all day long. It's about being pragmatic. It's about knowing which tool to use for the problem at hand. It's about having an eye for details. It's about communication and collaboration. I could go on all day.

And a big part of going from coder to developer is by practicing all of the above at home. Yes, maybe it seems a tad absurd to actually setup a continuous integration environment for one person. And yes, maybe it's a bit unrealistic to hold yourself to milestones for a side project you'll never release. But I guarantee you'll be better off for it.

So let's hear it. It's a simple yes or no question: do you write software at home like you do at work?

And be honest because if I ever interview you, I'll find out ;-)

18 comment(s) so far

You write software...at home? ;-) My response is no. Not that I wouldn't but I've yet to embark on a software product yielding anything but a demo for a presentation. However, when I do, I would configure the environment you outline above--I really can't develop effectively without source control, CI, harnesses, automated test execution, code analysis, etc. That said, most non-product shops I've worked in lack much of these facilities.

"...most non-product shops I've worked in lack much of these facilities"

Jeff - yea, that is a sad state of affairs. I can't work without any of that stuff, so getting a company/team to do it can be a challenge. But that's why you get paid the big bucks as a consultant ;-)

Should have numbered the questions :)

Personally, for my "personal projects", I'm probably more obsessive about code "cleanliness" and formatting, since on a team with others, you can't always control the spacing/tabbing that they use. I always use source control, and have been getting used to frequent check-ins. Don't use CI on my own stuff, but wouldn't mind. I only write tests on stuff that would get publicly released, which I have some in the works.

Overall, I think personal projects are easier ways to learn this kind of things though. Learning how to write good tests can be hard on a massive project, but easy on some of the smaller things you do yourself. And the take away is it benefits your day coding as you get better at your night coding.

Let's see:

Yes, TFS (used to be Vault, still have to migrate some things).
Yes.
Multiple checkins.
Yes, TFS.
Yes, TFS.
Yes.
Yes.
Pretty much.
Yes.
Yes.
Yes.
Yes.
Yes.
Yes.
Yes.
Not yet (I don't _that_ much at home; I kick the build manually).

Unfortunately, many customers I have been at are lacking in most, if not all, of these items.

So you'll reveal what tools you leverage to address the above needs...?

I would say yes to all except setting milestones and holding myself to them. They're side projects so I work on them when I can.

Sadly, some of the contracts I've been on do very little of this but I try to bring as much of it to the table as I can.

I have two kinds of personal projects: the ones I treat for real - like I did with WIWM and the ones I just do for the fun of it - like TFF Ratio started out. The ones I treat seriously I do most of that stuff. The serious ones I setup in CI, the fun ones I do not.

I'm not a full-fledged TDD'er so I don't write tests for everything, but I do write tests for anything I'm worried about or I know might be complicated (or new to me).

I never use bug tracking tools or task management tools for myself. I take that back - I make lots of notes for myself, whether on my mousepad (which is a notepad) or in Outlook/email/etc.

I always use subversion for everything no matter what. If a sample grows beyond a single file then it becomes a project and I add it to SVN.

abu_alfouz wrote on Tuesday, March 25 2008

I do write software at home better than I do at work.

Just three things:

1. Of course it is completely different. At work we develop software as a team process, at home i am normaly alone :) There is no need to control the process as SCRUM tasks as we do in company.

2. My personal preferences regarding IDE, OS and other tool related questions such as programming language, coding style and version control differ from the framework within the company (which is always a result of compromising).

3. As I see programming is a kind of art the development process at home is more like creating something which is aesthetik and some kind of beautiful but not just profit oriented as it is in the industrial development process in organizations.

I hold myself to higher standards at home with test driven development on my open source projects.

yilmaz wrote on Tuesday, March 25 2008

yes I am working on some hobby projects
lets see
yes
yes
yes :)
yes
yes
yes
no
no
yes /no depends on project
tes
yes
yes
yes
No Do you have a build server?
No
no

Rickasaurus wrote on Tuesday, March 25 2008

I usually don't stress too much about my toy projects. If i'm going to give it to other people then it's a different story though.

I would say at home, my quality of work is better than in my day job.

The reason is I find Mercurial makes it easier for me to commit code and easily refactor it, while at work I end up spending a lot of time just fixing bad SVN commits, so I have less time to code.

My home coding also allows me more experimentation that work, but that may change soon.

B. Waite wrote on Tuesday, March 25 2008

Funny, I expected this article to ultimately ask "why don't you write code at work like you do at home?", and not the other way around.

For me the quality really comes out at home.

Why?

1) No cost pressure. I don't have a budget to stick to.

2) No time pressure. I don't have a release schedule breathing down my neck.

3) No risk pressure. I can refactor code ruthlessly without freaking out about introducing some oddball bug that noone can predict but brings a production system to its knees.

Cool post - interesting question. I definitely try to write clean code, no matter where I am.

Regarding the other practices, I guess it depends. The amount of discipline that's needed is probably proportional to the complexity of the system, size of the team, etc. It seems like just a cost-benefit calculation...not a dogma thing (i.e. you should *always* use CI, or bug-tracking, etc.). You use it if it helps you and don't if it doesn't. In some cases these things are too much overhead...in other cases there's definite ROI.

That all said, SCM is a must;)

One of the great things about having a blog is getting comments from people. Some posts get no comments, some get one or two, and then there are some that generate several comments , effectively turning those posts into discussions. But there are downsides

One of the great things about having a blog is getting comments from people. Some posts get no comments

Post your comment

Comment