Self Modifying.

I read an article recently by Robert Dempsey about how he has recently discovered mind mapping as a way to manage user stories.  His technique was interesting and it gave me the excuse I needed to take another shot at mind mapping.

I’ve tried mind mapping in the past and it never really stuck for me.  It was a little too free form.  I needed some structure for my ideas, that’s why I was looking for something in the first place.  Robert’s post briefly describes the structure that he has used for forming user stories.  The method made the idea click a little bit better.  Basically he starts with the project in the center and then the ring out is the different actors.  Hanging off the actors are the actions that they should be doing.

I downloaded the 30 day trial of MindJet MindManager and tried Robert’s technique out on my current project.  It was a lot easier to get started that it had been on previous attempts with mind mapping, but I kept feeling like something was missing.  Here’s what finally clicked for me: what the user does is less important than why they want to do it.

In the classic user story we have an actor, an action, and a business value that the story provides (As an <actor> I want to <action> so I can <business value>).  I slightly modified Robert’s approach and added a level for business value — the “so I can” clause of a user story.  Now I have the project in the center, next the actors, and then I start listing out the business value that each actor wants to get from the app that we are building.  Under each of these leaves I can then start describing actions that would provide the actor with the business value.

This really make things click.  My ideas started to come together and I feel like the result is clear user stories that are customer business value focused.  I need to thank Robert again for convincing me to dig in to mind maps again.  I think this will be a big help in focusing my ideas in to something communicable and implementable.

Google recently announced their SPDY protocol that they’ve been working on to address a number of inherent non-performant aspects of the HTTP protocol that most of the web depends on.  In the last few years the web has shifted much more towards real-time applications.  Web application development is starting to think about interaction experiences much closer to desktop apps.  It’s not out of bounds to consider the response times of certain queries on a website in terms of keystrokes (~200ms).  Moving the request/transmission protocols to catchup with this change makes sense.

One thing that I am happy about with SPDY is that is appears to be built with deployment clearly in mind.  This isn’t the first attempt to improve web speeds, it’s not even the best, but it does appear to be the simplest to deploy in to the wild and see rapid adoption.  If Apache and Firefox gained support for SDPY out of the box, and it was show that using the protocol would improve server throughput, it would be enough to shift most websites over.  That’s only two players.  That’s pretty promising.

No.

If you are in a position to ask this question I humbly recommend you default to: “No, I do not need this as an instance variable right now.” There is a tendency to plan for every potentiality when doing software development and this is a prime example of such a situation. Resist the temptation.

Instance variables represent state associated with an object in memory. When you declare an instance variable you are saying to all future developers: “This piece of state needs to last for the life time of this object because it will be used elsewhere.” Think very hard about that. We are saying loudly here that this variable is coupled to other fragments of code. Which code? Dunno, do a global search .

This is called tight coupling. I will go so far to say that coupling is the source of all evil and complexity that we deal with as programmers. With every step that we, as programmers, take in building a system should be with an eye to reduce or at least not increase the coupling in the system that we are working on. The fewer instance variables that we have in a Rails controller the smaller the potential coupling between the view and other method calls that have access to those instance variables. Each method, each action in a controller, should be as self contained as possible. The less leakage of state out of a function the better. Generally your view doesn’t need to see that temp variable of the calculations that you made to set a model attribute keep it local, drop the “@”. Worst case scenario you go back and refactor your code to include that “@”.

My recent work has had me diagnosing some fairly common issues that one sees from developers moving from a language like PHP to Ruby on Rails.  The PHP philosophy (as I remember it) is to not restrict how you work and to seamlessly weave your code and your views together.  For very small websites this is fine.  I’ve even been told that this works really well for situations where most of the work is happening elsewhere (think Actionscript and Flash), which forces a kind of modularization.  Regardless we end up with lots of code and the persistence/database ends up being where we put things to remember them.  I’ve started calling this logic-driven design.  I’m not sure if I’m stealing someone else’s term, but it communicates the essence of the idea.

Logic-driven Design
To me LDD has a few key markers that make it stand out:

1. The persistence engine is used to store data and little bearing on the logic of the larger system.
1. There is no abstraction layer in which to place business logic.
1. The business logic emerges out of the flow of logic, rather than from some modular abstraction.

Most PHP programs that I have looked at fall in to this category.  Only as the project size grows past a certain complexity does one see PHP projects with more explicit abstractions around the persistence layer.  The reason this is done is because at a certain size in a project a programmer can no longer track all lines of logic in their head and continue to develop the application efficiently.

Data-driven Design
This addition of an abstraction layer around the persistence engine that is used for managing business logic is what has been called data-driven design.  This is obviously not a new idea.  In fact one of the points of pride for me in using Ruby on Rails is it’s particular grace in working in this manner.

Data-driven design aims to drive the logic and output of the application directly from the persistence engine; the data source.  The convenient side-effect of this design approach is the adjustment of most of the business rules and how the application behaves is matter of changing records in a database.

PHP to Ruby on Rails
Ruby on Rails employs an MVC architecture.  This architecture is designed to support data-driven design by providing a powerful abstraction layer for the persistence engine (the model).  Rails has a particular sweet spot for social web applications for this reason.  The framework excels in user generated content, as this is a form of data-driven design.

Developers moving from PHP to Rails often miss this shift in thinking when they make the jump.  The result is code that is primarily located either in the controller or the view layers, since this is analogous to PHP’s logic-driven model.  The end result is very heavy controllers with big functions that do a bunch of logic on database records, and then render it out to the user.  In this paradigm the Rails models are only used to retrieve the record and nothing else.

When Rails moved from solely MVC to a resource-based approach a few members of the community had some negative feedback.  Some people feel like the resource concept makes development in Rails more complicated.  What I’ve seen in practice however leads me to believe that the real difficulty with the resource based approach is that it forces you to make the jump from logic-driven to data-driven.  PHP style development becomes contradictory in a resource based rails application.  Instead you have to think about the “resource”, the entity that will affect and be affected, and build your application around that.