Documenting Documentation

I recently waded back into simple web application development (more on how that feels later), and one of the many aspects of coding that I’ve been refreshing myself on is how to best document what I’ve written so my future self doesn’t get too confused over what I implemented or why I implemented it in the way I did. The application is deadly simple, so simple that I hesitate to call it an application. The web page contacts a PHP script via an Ajax call, and the PHP script does its thing, sending back a JSON-encoded object. The client subsequently uses the object to display a message of success or failure.

As I said, deadly simple.

Nevertheless, as simple as the application is, I’ve been researching how best to document PHP and JavaScript. For PHP, the definitive answer appears to be phpDocumentor 2. For JavaScript, there is JSDoc. Here are some additional links that I found useful:



Note that I haven’t actually tried generating documentation with either toolset; that’s a completely different challenge. I’ve mostly been following the format so that my documentation can be printed/generated if somebody (aka me!) wishes. And what I’ve come to understand is that learning how to document a language feels almost as complicated as learning the language itself.


Agile Documentation and Research Stories

A few months into our switch to a more agile process, it became apparent that we still weren’t able to find a place for documentation in our sprints.

At first we had the idea that we would add a task to each story that would cover documentation. We found that we would end up writing docblocks and general code documentation but actual user documentation never got written. But we did that before so we really weren’t getting done what we were trying to get done.

Our next attempt was to set aside a day at the end of the sprint where we would write documentation or finish up stories that were not done yet. But I’m not sure how other people are doing point allocation in sprint planning but I think the ideal is to try to go just a little over the to of what you’re capable of. That keeps you working hard. At least for me, if I know I can do 50 points in a sprint and I schedule 40, I will get 40 done. Work expands to fill time. My point is there is always work to get done on the last day of a sprint. Scheduling documentation within the sprint separate from story points just doesn’t work.

That brings us to documentation stories.
As a developer
I need to document this functionality
So I can easily refer back when there is a problem in the future

This would be great, if during sprint planning, these stories actually got priority. The client wants a cool app, they don’t care about user documentation when you could instead be giving them a bell or a whistle.

What we have had are research stories. These are stories where we investigate options. i.e.
As a developer
I want to figure out if X is doable
So I know if this technology is the right way to go

These stories come up often in our process. We typically have been simply making some notes and reporting back at the retrospective / next planning. This was fine for our purposes but then we realized we could be creating a slightly more professional looking set of notes and pass them off as user documentation.

This doesn’t cover every aspect of user documentation, but it can get a lot of useful documentation done. How did we do our ldap data? We have documentation of our options and our final choice and why.

Currently we have been writing all of these in google docs so they can be easily collaborated on. We then paste them into the project wiki. It appears to be working.

Inserting images into Github’s wiki

This is something I was not able to find clear information on. Specifically, I wanted to add a flow chart I’d created to the wiki. I’ll also be adding an ER diagram later. It’s cool to have the important development documents somewhere where they can be accessed and perhaps edited from anywhere by anyone if need be. Github has a failing in this regard I think. They should have an interface for this.

The trick of it all is the wiki is itself a git repo. What you have to do is check out that repo. In my case, my project was To checkout that project, you would use the command:

clone  git at .

But that’s the project. The wiki is:

clone  git at .

So you have to check that out, add the image file to it, and then you can [[add the image]] via relative path image link.…