Tag: Agile

Building web applications the SaaS way

Posted by Neil – April 27, 2009

Recently, I’ve been finding myself writing more and more code using Ruby on Rails, as the demand seems to increasing. Whilst this isn’t necessarily a bad thing, it does mean that I am looking on things with a fresh pair of eyes having been using alternative technologies almost exclusively now for around 12 years.

So, what does this mean? Well, in essence, I’m discovering in the Rails community there appears to be a different way of thinking about things. With Rails (although this is more a manifestation of Agile), everything is centered around getting stuff done as quickly as possible to a level that suits the initial requirements.

As a supporter of this, there have been lots of hosted services springing up around the community related to providing elements of applications for a small fee each month that therefore means you don’t need to do stuff yourself. This has a number of benefits – you save yourself time, you tend to end up with a better quality product, and your costs tend to be lower. However, saying this, you also lose some of the freedom that you might otherwise need, and you have to accept the opinions of whoever is providing your ancillary services.

So, what sort of stuff have I been using that’s prompted me to write this stuff?

1. GitHub

GitHub is a simple one – it’s a hosted Git repository. This means that for a small monthly fee (it costs me $7/mo) I can have an offsite source code repository (with a simplistic bug tracker), a decent level of backups, and easy distribution with my peers who may or may not be inside the same infrastructure as me. Now, for me to do this myself would be a huge pain, and never as good as what GitHub provides – so why would I even consider doing this myself? Let’s say a billable day is a grand, I’d have to build GitHub in about a minute to get better ROI.

2. Mosso

Mosso is something that you should all be familiar for by now – and if not, go check them out. Mosso is essentially the same as Amazon’s EC2 service whereby you can create a server and run stuff on it as if it’s your own, but unlike Mosso, it’s a persistent entity. You can shut down a server and bring it up again as it was with no problems – almost as if it were your own server. Total cost to me? About $10/mo. Again, this is MUCH cheaper than doing it myself. Normally someone like myself would need to work for an entire day just to offset the server itself. With Mosso, that day can pay for 150-odd months hosting.

3. HopToad

Hoptoad is a funny one. It’s not a service you necessarily require, but more of a an ancillary service which makes you look a lot better to your clients. In essence, it’s a Rails plugin that means that application exceptions get raised into Hoptoad as well as whatever else you might have set up. This then gives you an application which tracks errors in your applications, their frequency, details and metadata (like the deployment version etc). At a cost of around $5 it’s dirty cheap, and can definitely keep you one step ahead of your clients when the errors start popping up.

and (4.) Rails itself

OK, so Rails isn’t necessarily a plugin, or a service, but it does offer opinions and standards that mean you don’t have to even think about doing some things, which in the end saves you time and makes you happy.

So, overall, there’s a fair saving out there to be had if you don’t go for the default I’m-a-programmer-I-must-write-it-myself state, but instead consider what other people can do for you.


Agile Requirements – How do you eat yours?

Posted by Neil – March 16, 2009

One of the things that I have been looking at a lot recently is the definition of what we, as a team, are building – a commonly missed task by many teams which can often lead to cowboy coding.

Now, there are many viewpoints on how this can be done, the age old preference being that of creating a 10,000 document that everyone must adhere to and be measured by. The trouble is, the document takes months to write, even longer to get approval on, and then an eon to code. By the end of this process, the document owner has retired, the development team have cycled their staff three times, and your dog has died. But, more importantly, because these days is moving so damn fast in business, your document is now worthless as half of the requirements are now invalid – either because the workflows in place have subtly changed or the market the product is aimed at has.

So, what do we do about this? Do we just ignore the requirement making it up as we go along, or do we do something a little more clever. Most people seem to leave it to making it up as you go along.

  1. Ask engineer how the damn thing works.
  2. Deafing silence.
  3. Crickets.
  4. Tumbleweed.
  5. Just start writing something. Anything.
  6. Give this something to the engineer.
  7. Watch engineer become quite upset at how badly you’ve missed the point of everything.
  8. As the engineer berates you, in between insults he will also throw off nuggets of technical information.
  9. Collect these nuggets, as they are the only reliable technical information you will receive.
  10. Try like hell to weave together this information into something enlightening and technically accurate.
  11. Go to step 6.

Well, at Monochrome, we’ve been doing Agile now for a fair while, and the key mantra there is

“Just barely good enough“

But what does this mean? Well, in essence, don’t bother doing anything until literally just before you need it, and even then, only do the absolute minimum to makes things work. If you do things to early, you’re opening up the risk of change, and if you do too much, you’re pretty much wasting your time (the minimum amount is just enough after all). This means no massive tombs of out of date guff, and also a lot less time spent writing.

For us, we find that documentation in the form of multiple screen wireframes that are annotated with functional detail tend to suffice, especially when accompanied by some background blurb to describe the things you can’t see. This is especially effective for two reasons – firstly it’s nice and visual, which means clients are more likely to read it, and it also gives you a nice document to directly compare your screens and functionality against – it’s almost testable.

Now, here’s a question back to you guys, all of which will be either reading, writing or somehow interacting with requirements on a daily basis – how do you eat yours? What do you find works, and what do you wish you could have?