Write It When You Need It
Or, don’t write code you don’t need
About a month ago I decided I wanted to build an app that would motivate me to write regularly. I had a vague idea of things it might do to make writing a habit, rather than a chore, so I sat down and made a list of all them — all the little bells and whistles that I felt it needed in order to be what I had in mind.
It was a really, really long list.
This was both good, and bad. Good, because for the first time I had in my hand a list of meta-things that motivated me, things that got me excited about writing. That alone was eye-opening.
But the list was bad, too, because it was too long. Looking at that list of features and ideas, I struggled against a sinking feeling in the pit of my stomach. It was too much. I could never write this. It was too big.
So I set the list aside and went back to using Scrivener. It worked — I wrote every day, a few hundred words at a time, but I kept coming back to the thought of this unwritten app. I couldn’t stop thinking about it. The core idea kept nagging at me.
I had to try.
I started another list. What was the bare minimum that I needed in order to start using this new app? What could I absolutely not live without?
This was a much smaller list.
- Text area for writing. A writing app is really no good without the ability for you to write something.
- Daily word count. For my purposes, this was at the core. Seeing that word count increase is pure dopamine for me. If I had to choose one core mechanic to encourage me to continue writing regularly, it would be this.
- Projects. This wasn’t really a make-or-break, but given that I typically have at least two writing projects going at the same time, I wanted the ability to categorize my writing based on which project it was for.
That was it, really. Three features. I could do this.
So I made an ugly (no, really — ugly) prototype in HTML, figured out how I wanted the basic layout to be, and got to work building the first proof-of-concept in Rails. (Rails 5, no less. This doubled as an excuse to play with something shiny and new.)
I decided early on that a plain text area was insufficient for what I wanted. I needed some basic formatting, too — italics and bold, if nothing else. But that was okay, because that meant I got to play with Basecamp’s Trix editor.
The first version was effectively two pages: the index, which listed the compositions from newest to oldest, and the writing page, which had the editor and the word count. I backed it all with a SQLite database, and ran it locally for a week with Pow.
And you know what? It worked! It wasn’t perfect — for one thing, I was used to indenting paragraphs, and using underlines instead of italics, and Trix does neither, out of the box — but it worked. Every day I sat down and watched my word count increase. And pretty much every day, I’d scratch myself (metaphorically) on some rough corner of the app, and I’d take a half hour or an hour to polish it a bit. Autosave came early, saving the document every fifteen seconds. Figuring out how to scroll the Trix toolbar with the page came soon, too. Better styling was surprisingly urgent as well — looking at something ugly becomes discouraging, and it doesn’t take much to make something that doesn’t hurt to look at.
The first new feature I added was “lists”, so I could keep track of loose ends, name ideas, plot points, items to research, and so forth. But I only implemented as much as I needed.
In fact, that‘s been kind of the theme of this whole experiment. Only implement as much as you need. I needed to be able to create lists, and add items to them, so my app currently lets me add items to lists, but not delete or edit them. Why? Because I haven’t needed that yet. The handful of times I’ve needed to delete something, I just used the Rails console.
Also, the UI for adding items is total judo. Instead of spending precious time writing Javascript and CSS to display a pretty form in-place, to prompt for the text of the new item, I just use “window.prompt”. The entire app, actually, makes use of “window.alert”, “window.prompt”, and “window.confirm”. Is this a pretty way to do it? Would it pass muster for an actual, production app? Ha, no. But it suffices for my experiment.
I’ve since moved the app to PostgreSQL, and have been running it on Heroku for about a week. (This because my 14yo son wanted to try it, which is nice because now I have my first alpha tester.) Having another person on it meant I needed to implement a User model, and authentication, so my app now has three pages: index, editor, and login form! (Feature creep, here we come!)
By keeping my requirements small, I’ve been able to iterate very effectively on this app. I’ve been slowly adding other items from my (longer) feature list, too; most recently, I added a chart showing how many words were written each day for the last two weeks.
Am I winning any races in bringing this app to market? Hmm. Probably not. But I’m learning a lot about what the app really needs, and by dog-fooding the app — using it myself every day — I’m learning what hurts, what works, and what I can’t live without. No guesswork, no overwhelming feature lists.
And best of all, I’m not wasting time writing code I don’t need!
My writing app is far from done, and is actually barely presentable. There’s a lot more work to be done on it, with no real timeline for getting it done, but if it sounds like something that might help you write, too, drop me a line and let me know! I’ll shoot you an email when (if?) it’s available.