It may or may not come as a surprise, but writing software is hard. Having spent the last 3 years doing it for a living, I’m finally making time to develop a side project. I don’t have a proper name for it yet, but I don’t think I have to worry about that for quite a while.

I’m struck by how easy it is for me to write code at my job, where all products are in well-known locations and I’m very familiar with the code base. Creating an application from scratch is turning out to be a whole different animal.

I’ve been going back and forth on design decisions, agonizing over which features to start with and how to go about implementing it all together. And the main thing I learned is that writing code right away really is the worst thing to do. I made the mistake of ignoring that rule and paid for it by re-writing the same feature 4 or 5 times.

So below is my list of recently learned through experience things to know about writing a new application.

Lesson 1: Gather All Your Features in One Place

No, “it’s in my head” doesn’t count. Have a piece of paper or a text document that lists every feature you can think of. Then walk away from that list. Come back to it in a bit and read it over again — remove features that aren’t essential at first. Trim it down to the bare minimum that gives you a functional application. It may take a few iterations to get down to a short list of prime features.

Once that list is ready, prioritize core features over fancy “wouldn’t it be cool if…?” ones. And last but not least, think over every feature — what is needed to implement it? Will you need to pull in some third-party frameworks? Are there any particular design considerations or concerns?

Lesson 2: Figure Out All Workflows

For each feature on your short list, write out a detailed workflow. For example, in my application, the user can create new “To Do” items. So I write out that workflow:
1. Click File->New…
2. A dialog comes up where the user sets task parameters and notes.
3a. User clicks Cancel and the dialog is closed, discarding the information.
3b. User clicks OK and a new task is created.

I’d even sketch out the UI for each step, as needed. It helps.

Lesson 3: Write Some Tests!

It may be hard to wrap your head around how it will all fit together. The easiest way to get some progress is to write some unit tests. This will help you figure out what your classes might look like and help you arrive at a more easily usable interface.

Lesson 4: Don’t Settle on First Version of Anything

For each of the above lessons, I’ve found it helps to walk away for a bit and think things over. When you come back, you can look at things with fresh eyes and sometimes see things you missed the first time.

Lesson 5: Do One Thing At a Time

I find that I get distracted a lot while I code. Not by outside things like email or Twitter, but by tangential thoughts or ideas about what I’m doing. I keep thinking “oh, it’ll just take 30 seconds to fix up this one thing over here…” and before I know it, it’s been half an hour and I completely forgot what I was working on in the first place.

It is important to stay on track and on target. Make notes of things you think of along the way and schedule them in later.

Conclusion

It all boils down to staying focused and organized. Charging in keyboard blazing and starting to type out code will only slow you down in the end. It’s best to slow down, take stock of where you are and where you need to be, and form a plan to get there. Then work the plan and enjoy the feeling of productivity and motivation as you check things off and see your work produce tangible results.