Do I write software at home like I write at work?
Dave Donaldson asks "Do you write software at homer like you do at work?"
Dave wonders if we use the same discipline writing software at home (for our own use) that we do at work. I think the question is great, but I'm concerned about those developers that answer yes without thinking. In fact, should you use the same tools at home that you use at work? I'll answer all his questions for my own development, and I'll explain why I make the choices that I make. Here are the questions:
- Do you have a source code repository?
[BW] Yes. I make mistakes and I want to backup.
- Do you use it?
[BW] Yes.
- 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?
[BW] Somewhere between those. This will become more apparent as you read on, but think about why you checkin often at work. Does someone else need your work? Not integrating (via checkin) often means that different branches (each developer's working copy) get farther away from each other.
- Do you have a task management system?
[BW] Yes. I use the same notecards we use at work.
- Do you have a bug tracking system?
[BW] bugs = tasks, therefore they go on cards.
- Do you assign bugs a severity level?
[BW] Yes. But, it's a simple one. "Fix it now", "Fix it later", "Do this when I have nothing better to do".
- Do you set milestones?
[BW] That depends. Why am I doing the development? What's the pain? The milestones (if any) depend on why the work is being done.
- Do you hold yourself to them?
[BW] Related: If I was writing a Bracket Management system now, I've got a real external deadline approaching. It's immovable. However, if I'm just experimenting, no such external pressure applies.
- Do you use the same types of patterns?
[BW] Sure.
- Do you apply a separation of concerns?
[BW] As often as I do at work. Decoupling has both benefits and costs. Which is greater in this instance? (The same analysis should apply at work).
- Do you write clean code at home, or is it a mess just to get it done?
[BW] Habits are permanent. You have to follow the same practices at home, or the bad practices will bleed through.
- Do you write tests?
[BW] yes.
- Do you run them?
[BW] yes.
- Do you have a build server?
- Do you use it?
- Do you practice continuous integration?
[BW] No on all three. There's a reason. Why do you use these tools at work? I'll submit that it is to facilitate collaboration among the team. With a team of one you don't have the same benefits. A separate build server does ensure that I haven't forgotten to add files to the repository. Visual SVN does the same thing. So does delete / update / build (make a backup first). I have multiple development machines, and I use online folders to help me keep them in sync. That means I'm not concerned about a catastrophic failure on my desktop losing work. (See 'check in often' above). Continuous integration is the same. By definition, in a one person-development effort, if it builds on my machine, it builds on the build server. Running my tests on every build gives me the same results.
Now, I will submit that if I think of the CI server as an automated test server rather than as an automated build server, I start to think about possible benefits. Every checkin runs the test(s) in the background, and I'm continuing to work. But, that changes my habits. At work, I write tests, write code, see tests pass, check in. At the moment, without a CI server, I do the same thing. If I moved to using a CI Server (thinking it is the test server), my workflow might change to write tests -> check in (see CI build fail) -> write code -> Check in -> repeat until CI build passes (meaning all the tests pass). I don't think I want to adopt that process in my work environment. I'd likely break the build repeatedly every day. That's not good
My purpose in answering Dave's question is to get more people thinking. Underlying Dave's post are some values. If you follow bad habits in less structured environments, those same habits will creep into your more structured environments. Practice doesn't make perfect, practice makes permanent. Every time you break your own rules, you'll reinforce bad habits. That's especially true when no one else is watching you. Countering that is an understanding of why you follow certain processes. If the justification for a particular process doesn't apply, neither should the process. This is true at home, at work, and at other work locations. As I said above, I don't have a separate build server at home. I don't see the benefits on a single person project. At home, and at our office (< 15 developers) we use note cards to track tasks and bugs. That's a low-friction and reasonable answer for a small shop that's located in the same office (although folks do telecommute often, that's what phones are for.) I'm fully aware that the notecards don't scale to a large, or more distributed environment. That doesn't mean I'm against other tools, just that I don't believe they would be appropriate for us now.
By way of analogy, I use a basic claw hammer to hang a picture. That's the best tool for the job. When I'm helping to build sets, and we need to build several platforms and flats, I use the air hammer. Both choices are correct. It would take more time to setup the compressor, uncoil the hoses, get the compressor going and so on… I'm done using the hand tool before I even get the air hammer turned on. Of course, I can finish a whole platform in less time (including setup) using the air hammer. It's a matter of evaluating the goals, and picking the write tool for the job. The analogy still works for those practices where I use my normal work structure. Even for hanging the picture, I get the hammer. I don't use the nearest heavy object (like my wife's crystal candlestick). The cost of using the wrong tool (as opposed to the right lightweight tool) is rather high.