30 September 2012
It has been just over a year since I 'finished' the now abandoned Workbook. Over the course of its design and development I've learnt a number of key lessons which I've taken with me as I work on My Focusbook.
Prior planning prevents piss poor performance. You will never lose if you plan ahead. Ever. One of the hardest things to do as a developer is to stop and visualise a project’s details
Before starting to build even if you’re the only one involved. We love to make things come to life and the instant gratification that comes with the job is sometimes too hard to resist. But by not planning every aspect of the application and only having a general idea I wasted so much time on re-building old features to accommodate new features as I went. Most people view planning as an extra, unnecessary step between them and a solution. But I can assure you the worst outcome of writing a plan (and that could include a dot-point of features, a few wireframes, a database schema, what each page will do etc.) is that you have a record of every feature you had in your head at the time of inception.</p>
Know when to optimise
One of the pieces of advice I’ve heard all to often is don’t optimise if you don’t need to. This goes mainly for code (don’t make a 10 line method a 2 line method until everything is working) but it goes for features too, I think. For example, to let users search notes they had created, I took advantage of Postgresql’s search functionality and it worked fine for the number of users. I didn’t need to send queries off to a Solr server. I would have just been wasting resources running it. I did however build the functionality in locally, and never published it to the production server. The lesson learned here is that it’s important to know when to optimise. Know when to move a process into the background and when it’s fine to leave in the main thread.
Good, better, best practices.
NB. I don’t like the term “best practice”, it’s too absolute, so I’m using it loosely as there can’t possibly be a single best way of doing something. I mean sure there are conventions in Rails, but outside of that the right tool must be used for the right job. When I started writing Workbook, I had just started with Ruby on Rails and coming from a PHP background, it. was. glorious! But I had no idea what I was doing. I knew what MVC was and how to write basic Ruby code, but there was so much I hadn’t explored with Rails yet. At this stage it was still version 2.x, rails 3 / 3.1 and the asset pipeline didn’t come along for a few more months. So I had no idea what I should and shouldn’t be doing or what was deemed to be bad practice by the Rails community. It wasn’t until after I had written the majority of the code did I come across resources like
RailsBest to help point me in the right direction. I found a lot of what I was doing to be correct but only because I had used common sense to come up with a solution. Which brings me to my lesson learned. There is no blatantly ‘wrong’ way of coming up with a solution so long as it is considered and there is reason behind it not just a quick hack, these will always bring about more issues than they have solved
Test. I can’t stress this one enough.
I didn’t write tests for Workbook. I had no idea what they were or why I would need them. but after writing tests for My Focusbook, I have come to realise the importance of testing. Boiled down, it gives you a thumbs up, or thumbs down as to whether or not your application or (a certain part of it) is working or not. This provides a great overview of your features and lets you know if you’ve broken anything along the way (which I almost always did). Spend the time learning to test, much like planning, you just can’t lose with tests. An extra failsafe never hurt anyone, right? If I could give one piece of advice to anyone (and I’m not an expert) who is thinking about building an application (or anything really) it would be just go for it. If you’re passionate enough about what it is you want to do. Do it. Make as many mistakes as you possibly can, but learn form them.
“Wise men profit more from fools than fools from wise men; for the wise men shun the mistakes of fools, but fools do not imitate the successes of the wise.” ~Cato the Elder