Loccasions: Retrospective
The Loccasions application now allows most of the basic functionality that I wanted to produce. In the first post of the series that mentions Locassions (here), I set out with the following user stories:
- As an unregistered user, I want to see the home/landing page
- As an administrator, I want to be able to invite users to Loccasions
- As an invited user, I want to be able to create an account
- As a registered user, I want to be able to create Events
- As a registered user, I want to be able to create Occasions
- As a registered user, I want to see Occasions on a map
What is a Retrospective?
If you’ve never been a part of a real retrospective, this post is not going to change that. While there are many definitions of the term in the context of software development, I take “retrospective” to mean a “short or time-boxed meeting where you discuss what went well, what went not so well, what we can do better, and how have our priorities changed.” Usually, you have a team made of of product owners, developers, and other stakeholders to help review the latest iteration of your application. In this case, it’s just little ol’ me and 15 or so articles. In both cases, however, a retrospective is very useful and should be a mandatory part of any development process.
If you are the kind of person that is down with more formal definitions and the like, here’s a few to get you going:
- James Shore, from The Art of Agile Development
- Ian Burgess chimes in with a definition here
- Matthew Bussa runs through an example retrospective.
- A cup of How’d We Do? But not too much, it’ll ruin the dish.
- A cup of What Went Wrong?
- A dash of What Went Right?
- A smidgeon of Planning Our Next Iteration.
- Blame
- Anger
- Hyperbole (“Since X went right we should use it for everything!”)
What Went Wrong?
I set out to make the Loccasions series an expose on developing a “real” Rails application, as opposed to the many contrived examples we see on the web. After my first “iteration”, I don’t think I fulfilled this goal. First off, it is the rare application that is the brainchild and work of a single developer. Also, I made many decisions on technology, gems, and the like based on shaky rationale. If you remember, I chose MongoDB, basically, because I wanted to play with it. If this were a “real” app, I would have never made a decision like that.
In many cases, I became a bit careless with the code and the examples. This caused some of the articles to be very difficult to follow and me to end up with the dreaded “Well, It Runs on MY Laptop” type of application. It was only through the efforts of some Alert Readers (especially, Nicholas Henry…that guy is a machine) that this issue was mitigated somewhat.
I think I should have selected a deployment platform (which would have been Heroku, because it is how-you-say? SUPERFANTASTIC) early on and continuously deployed the application to it. That may have encouraged some more participation from the community, as well as made sure my technical decisions weren’t tromping all over deployment.
Also, towards the end, I all but forgot about the use cases. In a real application, I would have constantly been checking the user scenarios to make sure I wasn’t deviating from the path. At the end of this series, Loccasions may have turned out to simply be a more complicated contrived example of a Rails app, rather than the real app that I had initially put in my sights.
What Went Right?
With the negative out of the way, I think a lot of things went well with Loccasions. First, and most important, I learned a ton and had a good time writing the series. As developers, when we are enjoying our craft and we care about the problem we are solving, life is good. Also, I think the choice of Backbone for the client-side code was a perfect choice. The more I use Backbone, the more I like it. It’s just enough framework and just enough out of the way, resulting in a great coding experience.
I echo that sentiment about Jasmine. I have been hooked on Jasmine since I first found it, and it continues to impress. Again, Jasmine focuses on the bits that I don’t want to worry about, so I can just test my application. Furthermore, I think Jasmine encourages good javascript design, exactly like a testing framework should.
Lastly on the client, I really like LeafletJS. If you need a map in your web application, I can’t recommend Leaflet highly enough. Beautiful maps that are a pleasure to code against make it my current “slippy” map of choice.
On the server, choosing Devise was easy and has proven to be a great choice. Quite often, gems with the popularity of Devise can morph into Sasquatchian mounds of unusable code, but Devise doesn’t feel that way to me.
Foreman, is almost an imperative now, in my opinion. Especially if you are deploying to Heroku, Forman just makes life easier.
Finally, I thought the pair programming episode with Evan Light was, arguably, the highlight of the series. In my new job, I work with Evan quite a bit, and he is every bit the Ruby brain and all-around good chap that I met writing that article. I wish I had done more of this.
How to Get Better?
The easiest, and likely most effective way, to improve Loccasions is to involve other folks. By adding another developer or two, this application would improve tenfold. One of the mantras I live by is the importance of developer collaboration. My best work has never been done solo.
Another group of people whose involvement would massively improve Loccasions are users. Getting people to actually use the application and give feedback would drive the direction of the app, and of this retrospective. In my many years of developing custom applications, I’ve watched our industry/community evolve from treating users as necessary evils to appropriately putting them in the driver’s seat. I remember reading a blog post (the author of which I cannot find….sorry!) that stated (paraphrasing) “You can always tell when a developer has designed your application.” This is certainly true of Loccasions, it could use a Designer’s Touch.
What’s the Plan?
Whenever I start the next iteration of Loccasions, there will be no shortage of things to do and improvements to make. However, I need to plan where I would focus next. After careful consideration, I think I would focus on:
- Deployment
- UX/Design
