Best practices when "going dark" (or going solo)

Question

I'm sure some of you would have read Jeff's Atwood's Don't Go Dark article. The gist is that it is anathema to go "lock yourself in a room" and perform a development task or project for long periods of time. The best practice would be to have a team (at least another person) with you, commit early and commit often, do your work iteratively, etc. etc.

This has become relevant to me because I have an upcoming "internal" project for a small travel agency business, owned and operated by my wife, and we can't afford to hire anyone for it (other than myself of course). The plans/specs that I've drawn up are a little ambitious, but now I'm beginning to doubt if I could pull it off in less than a year if at all.

My question now is, for those of you who have had no other choice but to do it all alone (e.g., people who have done successful one-man-projects, or people who are one-man IT departments), what best practices have you found so that you are able to:

• Produce high quality software
• Focus on your tasks and not get distracted or derailed in your work (especially in work-at-home gigs)
• Manage your time
• QA/test your software efficiently
• Maintain best practices in software development like source control, iterative development, etc.

I am particularly interested in people who have done work-at-home setups, as this is where I would likely do my work. I have to mention that we do have a 3 year old around the house, although we have hired a nanny to assist us with her, so that should be taken into account.

I'd love to hear your thoughts.

Answer 1

If you can't think of how to split the project up into increments smaller than a year, you're not just being "ambitious", you're being unreasonable. I'm the IT department for a small dental practice and have written much of the software used in it (tracking lab cases / supply ordering / document storage / etc). I try to keep any projects to less than a week long, otherwise my ideas for how it should work start diverging wildly from how my users actually think. If for some reason you just can't split this thing up, try to at least get the user interface mostly working so you can run prototypes by a knowledgeable user or two.

Answer 2

It is really difficult to do this yourself. Do all you can to involve someone else -- regardless of what they can contribute. Someone to bounce ideas off, someone to lend a hand with testing, etc. Anything. Doing this solo is hard.

Having said that, even for a solo effort, do the work as if you're part of a team. Do all the things you would in a team: proper source control (a given, even for solo work), run a wiki to track notes and architecture ideas, have regular progress reviews, etc.

Answer 3

I work at home 3 to 4 days a week. I have two children ages 2 and 7 and they fight like cats and dogs. I built an office in the basement where I can get away from the wife and kids and where it's quit. I go to work at 8am and I say I'm going to work to the wife and kids (even though I'm just going down stairs) and I make it clear that I've "gone" to work (as much for myself as them). I take lunch from noon till 1pm and work till 5. I find music help keep me motivated and on track - I find trance/techno & house to be the best for me. I schedule myself to work on certain things for a set amount of time with due dates in my calendar. I spend a lot of time using, running and testing the software I write, probably 30-50% at time, plus I get the users involved early on and encourage them to test THEIR system. I read a lot of blogs and listen to podcasts like dotnetrocks and hanselminutes to stay abreast of what's new.

Answer 4

Start by designing it with all your ambitious specifications. Then when you start implementing, get something that works as minimalistically as possible and gradually add features. If you've designed it properly, you should be able to drop in more sophisticated components for your more basic ones. You may even find that something that sounded like a great idea isn't that important after all.

As far as testing and Q&A goes, make sure someone else is using your software (in this case your wife) so they can provide feedback and suggestions for improvement.

Answer 5

I've worked as an only developer on a big project (about a year later other people joined). I find that it's helpful to follow most of the usual practices (as you'd do with a team), and not rely on keeping things in your brain:

• Use source control, no excuses.
• Write a basic and brief functional spec and review it with your business partner. (I find a Wiki is good for this, since it's easy to edit and share). It helps to have a clear vision of what you're trying to create, rather than just pile on ideas.
• Break down the work into several high-level items. Fill out lower-level subitems as soon as they're clear.
• Use a bug database for work items as well as defects. You can use it to prioritize features.
• QA: Do as much dev/unit testing as you consider efficient, but do have someone external (maybe your business partner/wife, doesn't need to be a developer) to act as an independent tester. Functional spec that you wrote/reviewed together will come in handy here, so they know how things are supposed to work. You'd be surprised at bugs devs miss (we rarely look beyond our own assumptions).
• Plan to have a rudimentary / testable version working after a month or two, and then add features. Small, achievable milestones help.

Answer 6

In projects in which I had no one to bounce ideas off of I've found it helpful to write them down, wait a while (usually about a week while working on another feature), and come back to them, effectively bouncing ideas off of myself.

Answer 7

I'd say, don't go dark.

Try and follow at least some of the agile methodology - have scrums with the stakeholders as often as you need to and work off their feedback to keep you motivated.

Break the project up to small managable chunks that you can tackle - get something prototyped that you can get feedback on as a first priority and start getting your feedback loop off that, use that to motivate and drive you on further iterations as you add features and broaden it from a skeleton.

Still do your source control as if you were working as a team, check in often - because having parts checked in is just good practice to keep backups of your work, check-ins help motivate me because they're parts I've completed (at least until they're refactored, then they're motivating because they're parts I've refactored!)

I'd try and go TDD, because it gives you better testing of your app, it gives you feedback on what you're doing, what you're breaking, it gives you something that you can look at (test counts) and see how much progress you're making, and a run of green lights couldn't hurt.

Set up continuous integration, so you don't have to be running tests all the time - it does it automatically, same with FXCop, etc, and so you have releases building, and it gives you more incentive to check-in.

A lot of tools like TeamCity (CI), Vault (Source Control), etc all have free or cheap systems for single programmers that can help you.

But for the most part I'd definitely get the project planned as best you can, get small chunks you can work on that make it manageable, so you can keep timelines, and knock them over so you feel motivated to keep getting to the next milestone.

Answer 8

You might want to change the title to "going solo" than "going dark" because you're describing a situation where you are forced to work on a product yourself rather than keeping it all to yourself.

Working with yourself is tricky... very tricky as it requires you to be very self disciplined. But I found the following to help whenever I've worked with the few hobby or internal projects that I have:

• Plan out what features that are needed and prioritize them on both simplicity (i.e. the time you think they'll take to make) and severity (i.e. how crucial is the feature). To keep a feature granular enough write them as stories that explains the W's of the feature. Example: As a travel agent I want to see a list of cities at a vacation spot of my customer's choice so I can recommend a customer the alternatives.
• Start small and simple. Begin with implementing the easiest features and work your way through the feature list.
• Test early and often. As you make your features, test them out. And the code you have should be workable after each feature you've implemented.
• Always make sure your features are DONE.
• Always use source control! There is no excuse to not handle revisions of and back up the source code. If you're in a spot where you've broken your code, then it is always nice to revert back to when it last worked
• Keep a bug list. All bugs found should be put on a list because they're very easy to forget as you hack away.
• Always think about your code design with the question "How will this feature impact the code you have now?"

And... good luck with your project. :)

Answer 9

I changed the title as suggested by Spoike. I do acknowledge that "going dark" is not entirely accurate because most likely the main stakeholder (i.e., my wife) will be able to provide feedback for me.

However in a sense I will still go dark because I don't have a co-developer who will point out my WTFs for me.

Answer 10

There are some good answers here already. As a developer who has worked as a 'one-man-band' company for a number of years, occasionally bringing in sub contracts (and briefly, some employees), but mostly working alone, I have a few points for you to consider that I don't think were covered in the other answers.

1) Working at home is much, much harder than most people appreciate. I had a terrible time working from home to begin with, then I got a little 'lock-up' office and things changed dramatically. Recently I've had to go back to working at home and it can very difficult to deal with the distractions (and right on-cue as I type this, the cat walks in and meows at me for attention!)

If you can get yourself a room 'away/apart' from the rest of the house, it will help. If you can get a room where you can close the door, and the room has no other real purpose than to be your office, so much the better. You really want to try and maintain this idea of you being at work, both in your head and in the heads of the other people in the house. While you're working, you're not really able to run out for groceries or do other domestic chores, however much they may play on your mind etc. Save them up for your lunch break, exactly as you would do at work. Even little 'psychological' things, like putting your shoes on before you go work, can help make the distinction in your head.

2) The biggest risk when you work alone on projects that are not subject to peer review with other developers is not the potential to write bad code. Instead, it's about overlooking functionality and not getting the requirements right. And, to a lesser but still important degree, that you don't disappear 'up your own arse' with things like user interface or 'clever' features that don't actually add any bottom line value.

As long as the testing proves that your code works, the real cost of bad code (or rather, code that another developer would help you improve) on an 'internal' project is minimal, especially if this is a 'start-up' project and you're just trying to get something out there for her to use.

But if some key component of the system is overlooked, or your understanding of it is flawed, the whole enterprise is thrown into jeopardy. I'd say you need to quickly get a non-functional mock-up/prototype so that your wife can role-play with it and take some 'ownership' of elements like work-flow and overall functionality.

No-one else is likely to see your code, in all honesty, and so as long as it does what it's supposed to do, I'd not be too concerned about HOW it does it - I'd be more worried about WHAT it does and WHY, and those are things that your 'customer' can help you with.

3) Try to work on small, closely defined pieces one at a time. When you're on your own it can be hard to stay motivated if you don't feel like you're making a lot of progress. You need to plan your work so that there is some degree of visible progress each week, however arbitrary or 'fake' it really is. Once I've mocked up enough of my screens and controls for role play, I pick one to start 'fleshing out' and I try not to get dragged into the other parts of the program that it will ultimately interact with. Leaving functions and procedure calls as empty stubs helps. You go back over time and fill them in, but you don't ever want to be in a situation where you've spent a whole week typing code into the same 2 or 3 unit files and don't have anything tangible to show for it - those kind of things can sap your momentum if you don't keep an eye on them.

I've got more but I don't know how useful you're finding this and it's probably too wordy already so I'll stop there (for now?)

Whatever you do, best of luck with it!

Answer 11

TDD! Those little green circles keep me feeling like I'm actually getting something done.

Answer 12

Did this once, liked it a lot. Had a 3 year old around too. And that job lasted for 4 or even more years.

If you feel you are an expert in your field, start helping other developers, that will help you get out of the dark room. Answer questions on related forums over the Internet for example, in your free time.

Answer 13

I have no choice but to work solo on my projects. The only thing that keeps me motivated in the interest to learn and create new things. Sometimes when there are very hard problems for me to solve I move on to something else, and think about it later, or ask here. I have been working in a home based environment. From experience I think these are the most IMPORTANT things to have when working on a project like you say:

• Comfortable work space
• A CLEAR list of tasks and goals
• Find the down time, so that way there are not outside sources distracting you from your work, because you might lose your train of thought, and it will make it hard to pick up where you left off.
• Personally, I work best with music in the background.
• A quiet place to go, preferably outside, to take a break when you need it.

In terms of testing what was made, and making sure that the quality is sufficient, I have a friend or family member critique me. If things are well you get a compliment and that is also a bit of motivation. So, having feedback is very important but you have to find the right source. Sort of a tough love kind of deal.

I have just finished a 500+ hour project that took a lot of hard work and stressful hours. I hope that my experiences can help you achieve your goals a bit easier.