Wednesday, October 26, 2011

Brainstorming Aesthetics

Yesterday I posted[1] about "writing it down" as an obvious and simple methodology that should not be skipped. Well, looking through my EverNote notes I realize I did start writing things down at the beginning. One problem with those notes, though, was that they're just stream-of-consciousness, mixing different levels of detail in too many words. Reading the notes from start to finish makes them understandable, but they did not serve to add structure to my thoughts. Instead they only served the purpose of leaving a record.

A better, structured brainstorming approach does the following things:

  1. Uses concise wording.
  2. Uses symbols and pictures, avoiding prose, when appropriate.
  3. Breaks out levels of detail into separate groups. Programmers should be adept at this.
  4. Lays out ideas to facilitate reorganization. One reason electronic brainstorming is very powerful.
  5. Gives multiple "entry points" for re-examination. If your brainstorm requires reading from top to bottom to make sense, then it's not as good as it can be. More entry points mean more opportunities for additions and updates in the future.
As an example of #3, breaking out levels of detail into separate groups: if a server needs to generate a token and send it to the client as part of some process, that's all I need to say for the top level. How the token is generated may belong to a different level of detail. Writing both together muddles the intent, and makes the notes difficult to read.

That's all I can think of now. If you have more suggestions, let me know.

Tuesday, October 25, 2011

Write it down

Recently I was thinking through a programming problem in my free time, for several days. (Authorization of purchases and content delivery.) After a week passed, I knew I had considered all the different cases, but couldn't get the whole flow pictured in my head. At each step of the authorization process, different issues come up where either a legit customer may lose data, or a pirate gains unauthorized access to content.

I was reluctant to write things down on paper (or electronically), since I felt I needed many changes to get it right. Writing it down would only add more overhead as I changed the design around. Unsurprisingly, I have a similar sentiment towards test-driven development, where in many cases the project being built out is too uncertain in requirements, and new features may be desirable later on, such that writing tests up front only adds overhead later on. Unit testing in general, though, is highly desirable.

After the week passed, I was at the point where I wanted to write down the design, so I could pick at it without spinning my wheels thinking about the same scenarios over and over. As you've probably guessed, writing it down helped me immediately see a couple problem spots and get the design down from start to finish. It also helped to have visual separation between the components of the process. In my head I would jump back and forth between components, like initial purchase versus restoring purchase history, trying to think "where can I reuse this security token and when do I need to generate a new one?" and things like that. Writing it down, even in just simple numbered lists, helped me split up concerns and stop wasting mental energy juggling different pieces.

The message of this post is hopefully obvious to most people, and even for me it is something I've learned and relearned many times over the years. It's just times like these, when my pride creeps up on me and makes me believe I can handle thinking all the way through moderately complex designs in my head, that I disregard an obviously useful methodology.

Thursday, October 6, 2011

backbone.js: Model.initialize() is called at the end

When is Model.initialize() called in backbone.js?

Just a quick post to indicate that in backbone.js, Model.initialize(attrs) is called after everything else is done, like setting the attributes if you passed them into the constructor. I'm only writing this down because it took me a few minutes to find the answer. I had to look at the annotated source.

The docs, and some blog posts, only say things to the effect of "you can provide an initialize function, which will be called at the time of construction" which is ambiguous--is it before or after the attributes are set on the object?

But now that I know the answer, I realize it doesn't matter--I don't want to be designing initialization code that is so fine-grained that it matters whether I set the attributes once or twice.