So one of my clients is a typical “iPhone app with a web backend” type project. I ask one of my guys to give me a web backend.

If I had done it, I would have implemented the web backend in Padrino, for Ruby, and had everything return JSON

I like Padrino in this case because it’s a very small framework, for writing small web apps - like APIs. I believed that A bunch of views that just returned JSON (nothing more!) was all that was required.

Instead, I get a Rails. Rails is a heavier-weight framework, for serious and complex applications.

In addition to the API, it also had an interface where you could see the data in a browser. Something that wasn’t in the requirements from the client.

I was really annoyed at my guy - I wanted something simple, and got something complex. I thought what I was given violated the principal of You Ain’t Gonna Need It (YAGNI)

1 week later, I was proved wrong, by a simple question:

Client: Doesn’t the web app also display all the information though, like WEBSITE X and WEBSITE Y do?

I wanted to answer, “No”… because “the user should be able to view their activities via siting the site in the browser” was never anywhere in the requirements.

And had I implemented the site my way (with Padrino returning just JSON), that would have been the correct answer. It would have been relatively hard to go back and re-work the website so a user could use the site from a browser (not an iPhone app).

(Yes, I know about Javascript-heavy front end tools (like SproutCore), and they could have used the API by making Javascript calls to it… but still a fair bit of work, just in a different area (Javascript, instead of Ruby)

Lesson of the week: YAGNI is powerful, but sometimes you are going to need it, and sooner than you might think.