The Code Dump

A place a coder rants at...

Lessons from Building a Rocket Alarm App

3 weeks ago Hamas started firing more than a hundred rockets a day at Israel. After almost sleeping through the sirens one time, I decided that enough is enough and went looking for a way to write an app for it. The iPhone had a single app that would constantly alert with a delay (of usually several minutes) – we couldn’t fly with that.

Air raid sirens 101

If you’ve never had to live in rocket range and duck for shelter (like most of the western world) here’s how it basically works: all of a sudden you hear this lovely sound booming across the city and now you have to run for shelter within 15-90 seconds (depending on your distance from Gaza strip).

A lot of apartments in Israel have a safe room that you can run to, but older buildings don’t which means you usually go to the stairs, since they are considered safer than the rest of the building. You then spend 10 minutes with your neighbors (or strangers that ran inside from the street), waiting for the rockets to fall or be intercepted by the Iron Dome.

Problem is that these sirens are easy to miss if you’re taking a shower, a deep sleeper, in a place where there’s some noise or happen to be in a place where the sirens don’t reach that well.

With the help of a few talented friends, we had a working iPhone app in about 20ish work hours over the weekend. Since then the app has topped the Israeli App Store’s free chart and delivered tens of millions of notifications. Here’s a random collection of things I’ve learned along the way:

  • Not that hard to top the Israeli store: On its first day, the app had about ~4k installs (mostly in the Israeli store) and those were enough to get it to #10 on the free chart. 2.5 days later it had ~24k installs and ~100 5 star reviews, which brought it to be #1 on the Israeli store.

  • Going viral in bomb shelters: This is a bit stupid but I was utterly surprised to see the amount of installs keep going up. I posted once on Facebook. It seems like from there the app was shared across the Israeli tech people which got a nice amount of first installs. But the real masses of installs happened after every barrage on big cities. I’ve seen this and heard from other people: as we stand in the bomb shelters for minutes, usually with neighbors and total strangers, people see you get alerts on time and lament the crappy app they’ve been using.

  • Testing is weird: We had scenarios of “well, I’ll just wait for Hamas to bomb us again to make sure it works.” That’s kind of a weird scenario to be in. But hey, you could always count on Hamas to deliver, even during ceasefires!

  • An accessible mail form will be triggered a lot: The app has a “contact us” button that just opens up the native iOS mail compose view with my email address. The amount of empty emails I’ve received (due to people just pressing “send”, without writing anything, instead of “cancel”) is nearing a 1000 (and we currently have about 70k installs). Be prepared.

  • People mostly want to stay updated: In times like this it seems Israelis really want to stay updated about rocket launches. It’s a small country and you know someone at every city – you want to know when your friends are attacked. Even though you can point the app to only alert for your own city, over half of the users have set the app to alert them for “every alarm” (over a hundred a day). That also means that the app was not just used for “I have to run for cover” but also as a news source, which is why I got hundreds of emails asking to add other notification sounds, “less alarming alarms” if you will.

  • People actually read the P.S. of emails: I’ve handled hundreds of support emails and in most added something like this: “P.S. If you’re satisfied with the app it would really make us happy if you click here and rate us well”. A lot of people replied with “already did” or “of course, you deserve it” and we actually have about 0.5% of installs that rate us (with a 5 star rating). I don’t know what’s the average here, but it seems to me the P.S. works.

  • Push permission is a bit of a pain: A lot of people did not allow push notifications when the app prompted them and then complained about not getting alerts. It was very hard to instruct them via email how to get to the appropriate settings screen and what to set in it. There should be an easy way to prompt the user again even if it hasn’t been that long since the last time he said no. Also, do yourselves a favor and put in your email form a user identifier that’ll help you see if the user has allowed push and other things. It’s otherwise almost impossible to identify a single user out of tens of thousands.

  • Parse is pretty awesome: We’re sending out millions of push notifications a day for free and the integration was a breeze. We once noticed a delay in delivering notifications and the Parse team were quick to reply and sort out the problem. Really amazed me!

Here’s to hoping the app goes idle soon!

Generic HTTP Error Handling in AngularJS

| Comments

Lately during development at one of our clients, Ravello Systems, we decided we wanted better HTTP error handling.

Basically, our perfect solution would have generic handlers for errors, and most calls in the code will not have to do any special work for handling errors. This means that things like authentication problems, server unavailability issues, etc. will be handled in one place — like adding a generic “something went wrong” modal.

But, we also wanted to be able to easily override these default handlers so that specific places can do things like silently ignore errors of unimportant calls (e.g. background requests that aren’t user-facing), or display a special “try again later” context—aware message.

This is a case study of how we currently implemented this. I’m sharing this for others that might need it and in hopes to hear of alternative ways to accomplish it.

Our requirements

  • The generic error handling should happen automatically, and can’t be something a developer can forget to enable. That means things like adding a ‘.catch(genericHandler)’ to every call is out of the question.
  • When the less common case happens, meaning someone isn’t using the generic handler, it should be explicit.
  • It should work seamlessly with angular’s $http service so that no matter if we aren’t the ones making the calls ourselves, everything should still be handled.
  • It should allow us to easily handle grouped requests (i.e. requests that are handled by the caller in a single $q.all() call).

How the end result looks

If you’re making a call that just wants to use the generic handling code, it looks like this:

1
2
3
4
5
$http.get('some/url').then(
    function(response) {
        // Stuff here
    }
);

Seems familiar? That’s right, in most cases you don’t need to change your code at all.

And in cases you do want to handle errors yourself:

1
2
3
4
5
6
7
8
RequestsErrorHandler.specificallyHandled(
    function() {
        $q.all({foo: FooService.fetch(), bar: BarService.fetch()}).then(
            function() { /* Handle success */ },
            function() { /* Handle specific errors */ }
        );
    }
);

As you can see, it’s pretty straightforward. And the use of a function (which we would essentially consider a block in languages like Ruby) allows us to group multiple requests in the same error handler.

The implementation

Basically we tag every request that needs to be generically handled by adding a HTTP header to it. Then when requests fail due to errors an interceptor handles those that are tagged.

There are 3 parts:

A decorator for $http – This is the only way we came up with to tag requests inside our specificallyHandled function. Interceptors are run asynchronously and so can’t tell whether the request was made inside our specificallyHandled block or not. This decorator simply wraps all the $http functions to add a specific header in cases they should be generically handled.

Response interceptor – This intercepts all the failed responses and handles them in a generic way – but only if they have the magical HTTP header we add in the $http decorator.

RequestsErrorHandler – A service that turns on or off the generic handling according to when it is called.

The Code

Also available here.

Angular Performance 101: The Slides

| Comments

I gave a talk today at JS-IL called “Angular Performance 101”. Below are the slides. Unfortunately they are a bit hard to follow if you haven’t been to the talk. I hope to upload a version with audio if people will be interested.

Cheers!

AngularJS: Decisions, Decisions & My Preferred Choices

| Comments

Angular is the land of too much free choice. You are faced with decision after decision, over and over again. Choice is good, but sometimes too much choice can cause paralysis. Let’s take a look at some of these choice and what I usually go with:

Factory vs. Service

Chances are you saw these two common ways of creating injectable objects, factory and service, and couldn’t help but wonder “what the f@#$@ is the difference?”

Essentially, factory takes a function whose return value is the thing that would be injected. So if we have this:

1
2
3
angular.module('app').factory('MyThing', function() {
    return {id: 1, thing: 'stuff'};
});

And you inject it, you will be injected with the object {id: 1, thing: 'stuff'}.

service is almost identical, except that it expects you to provide it with a constructor function. It instantiates a new object using that function and that is what is injected:

1
2
3
4
5
6
7
8
angular.module('app').service('MyThing', function() {
    this.id = 1;
    this.thing = 'stuff';
});

angular.module('app').controller('MyCtrl', function(MyThing) {
    // Here MyThing is {id: 1, thing: 'stuff'}
});

Note: Every place that MyThing would be injected it would be same instance. In other words Angular will instantiate a single instance and reuse it across your app.

Which should you pick? In general, since the two are almost equivalent I like sticking to just one of these in a project, usually factory. It can do anything you can do with service and I personally don’t see a need to go through creating a constructor that’s just called once. I just return that instance and that’s it.

Value vs. Constant

Angular lets us quite easily add simple injections of plain values. For example, say you want to declare a constant like your REST URLs base path. You can do it with either module.value('restBase', '/api/v2') or module.constant('restBase', '/api/v2'). Really?

The difference is that while constants can be injected to module configuration functions (i.e. module.config()) values cannot. Also, you can intercept values with $provide and decorate them. These are two usages are pretty uncommon and are for more advanced cases, so don’t worry right now if you don’t know them.

Since they’re so similar I’d just stick with constants unless your are using it to store something that is not actually constant (i.e. an object that you change later on). But that’s basically a global variable, so you probably should never do that. So constants it is!

Directive vs. Nested Controllers

For some uses, directives and controllers can be used interchangeably. We all know that directives should be used for DOM access and controllers are usually used for top-level elements like pages and routing targets. What about all the rest?

I’ll just cut to the chase: Almost always the right choice, in my opinion, is to use a directive. Directives allow you to write code that is more decoupled and self-contained. Directives let you to explicitly state what they depend on, opposed to controllers that just inherit their parents’ scopes as-is. More on this next.

Same scope, new scope, isolated scope

Now that you’ve realized that you should almost always use directives comes the decision of scope. Should you just use the parent scope? Inherit it? Isolate completely?

Well, my heuristic is: Will creating an isolated scope mess things up? For example, if your directive might be used along other directives/controllers that would not expect the scope to be swapped. If so: prefer to inherit the scope if possible, use the parent scope only if you must.

In pretty much any other case I just use an isolated scope. They are the best thing since sliced bread. Isolated scopes are explicit (it is easy to see what they depend on), durable (they are less likely to break because of code changes somewhere else) and plainly the way to go. I’ve described their advantages in “Writing More Maintainable Directives”.

Understanding Angular’s Magic: Don’t Bind to Primitives

| Comments

If you do Angular, chances are you’ve seen the rule “Don’t bind to primitives” quite a few times. In this post I’ll dig into one such example where using primitives causes problems: a list of <input> elements, each bound to a string.

Our example

Let’s say you’re working on an app with books, and each book has a list of tags. A naive way of letting the user edit them would be:

1
2
3
4
5
<div ng-controller="bookCtrl">
    <div ng-repeat="tag in book.tags">
        <input type="text" ng-model="tag">
    </div>
</div>

(You will probably want to add another input for adding new tags and buttons for removing existing ones, but we’re ignoring that for simplicity’s sake.)

A live demo of the example is available here. Go ahead and edit one of the inputs. It might seem like everything is fine. But it’s not. Taking a closer look would show that the changes you make aren’t being synced back to the book.tags array.

That is because ng-repeat creates a child scope for each tag, and so the scopes in play might look like this:

bookCtrl scope = { tags: [ 'foo', 'bar', 'baz' ] }

ng-repeat child scopes: { tag: 'foo' }, { tag: 'bar' }, { tag: 'baz' }

In these child scopes, ng-repeat does not create a 2-way binding for the tag value. That means that when you change the first input, ng-model simply changes the first child scope to be { tag: 'something' } and none of that is reflected up to the book object.

You can see here where primitives bite you. Had we used objects for each tag instead of a plain string, everything would have worked since the tag in the child scopes would be the same instance as in book.tags and so changing a value inside it (e.g. tag.name) would just work, even without 2-way binding.

But, let’s say we don’t want to have objects here. What can you do?

A failed attempt

“I know!” you might be thinking, “I’ll make ng-repeat wire directly to the parent’s tags list!” Let’s try that:

1
2
3
4
5
<div ng-controller="bookCtrl">
    <div ng-repeat="tag in book.tags">
        <input type="text" ng-model="book.tags[$index]">
    </div>
</div>

This way, by binding the ng-model directly to the right element in the tags list and not using some child-scope reference, it will work. Well, kinda. It will change the values inside the list as you type. But now something else is going wrong. Here, have a look yourself. Do it, I’ll wait.

As you can see, whenever you type a character, the input loses focus. WTF?

The blame for this is on ng-repeat. To be performant, ng-repeat keeps track of all the values in the list and re-renders the specific elements that change.

But primitive values (e.g. numbers, strings) are immutable in JavaScript. So whenever a change is made to them it means we are actually throwing away the previous instance and using a different one. And so any change in value to a primitive tells ng-repeat it has to be re-rendered. In our case that means removing the old <input> and adding a new one, losing focus along the way.

The solution

What we need to do is find a way for ng-repeat to to identify the elements in the list without depending on their primitive value. A good choice would be their index in the list. But how do we tell ng-repeat how to keep track of items?

Lucky for us Angular 1.2 introduced the track by clause:

1
2
3
4
5
<div ng-controller="bookCtrl">
    <div ng-repeat="tag in book.tags track by $index">
        <input type="text" ng-model="book.tags[$index]">
    </div>
</div>

This does the trick since ng-repeat now uses the index of the primitive in the list instead of the actual primitive, which means it no longer re-renders whenever you change the value of a tag, since its index remains the same. See for yourself here.

track by is actually way more useful for improving performance in real apps, but this workaround is nice to know as well. And I find that it helps in understanding the magic in Angular a bit better.

What I Wish I Knew Writing My First Billing System

| Comments

Billing code is probably the scariest that most coders get to work with. After all, for most of us it’s not everyday that we write code that literally moves money around.

I’ve gathered a list of a few things that you should keep in mind next time you set off to implement billing. Not all are a must have starting from day one, but you should have them in the back of your mind.

Frontend & UX

Don’t leave me hanging – There isn’t a person using the internet that doesn’t know the dread of having nothing visibly change after clicking a “Pay” button. Always show a clear indication that something’s happening. Charging takes a couple of seconds – design for this waiting your users have to endure.

Be clear about the “money time” – I love it when there’s a label near buttons saying whether that button is the one that’s gonna charge me or if there’s another screen after it.

Prevent double-clicks – This should go without saying, but you want to make sure the important buttons can’t be clicked twice, neither because of fat fingers or because the user somehow missed the indication that the click “took”. And none of that “don’t refresh this page” nonsense. Users should be able to go back and forth without fearing for their money.

Design for errors – Charging errors happen. A lot. People have typos, some cards can’t be billed for recurring charges and sometimes people just forget the billing address for a specific card. I’ve heard of people that put in bad data in the payment form just to see if the site seems “legit” and handles it correctly. You should pass along as much information as you have about the error that happened and display it to your user in a human-readable form. No general “error happened, try again” if you know the problem is the expiration date. No “CARD_EXPIRED” constants you got from the API. Write god damn words.

Business

Dunning – Sometimes things get screwed and the monthly charge of a customer will fail. It can happen because the card expired, has no credit available, was canceled, etc. You should handle these correctly and notify your user about this, “nudging” them to update their payment method. This is called “Dunning”. You might also want to automatically attempt recharging once they update their card or just because a couple of days passed.

Handle users in limbo – The other aspect of dunning is that it means you have users that haven’t paid yet for the current period, for whatever reason. You will need to decide how your product should behave for them (a grace period, changes in UI, hiding some features). I wouldn’t delete data or prevent access to business critical stuff before at least a couple of weeks have passed though.

Pre-Dunning – It’s basically better for everyone if instead of trying to charge an expired card and then mailing a “we couldn’t charge” notification you check for it beforehand. Write a bit of code so that a week before the monthly charge you check which cards will be expired and email the users asking to update their payment method now.

Plan for refunds – Every business has to refund money sometimes. You don’t have to create a super slick management backend system from day one, but you should know how refunds work and make sure your support staff has some way to issue refunds relatively fast and that your code will handle the situation appropriately.

Notify before first charge after trial ends – This is just good etiquette. We all hate when we forget some trial and see the charge on our statement later. Do the right thing and notify your users before the trial ends and charging begins. Also, this can save you chargebacks from pissed users which cost you a lot of money and can totally screw your processing fees if there are too many of them.

Backend

Make debugging and support easier – I’m very paranoid when it comes to handling money, and so I love having a kind of an “audit log” that tracks every billing related action that took place in the system. Someone tried signing up, upgrading, downgrading, charging failed, refunds. This is great for debugging.

Plan for pricing changes – When you start experimenting with different plans and pricing and need to grandfather users across plans you’ll need to know exactly which plan users signed up for, when and for how much. This can save your bacon when it’s time to move everyone around so make sure you have it all saved.

VAT and taxes – This can be a bitch, and I’m no accountant, so make sure you know if and when you should charge VAT and similar taxes. In the EU and other places it means you need to ask you users which country they’re from and adjust the price appropriately. You will also need to make sure you add the right line-items to your invoices and keep track of how much money isn’t really “yours”.

Take special care of DB transactions – You charge a user using some API, e.g. Stripe, then go ahead to save the user’s status as “premium” to the DB. The next line causes some error and the database’s transaction automatically rolls back. Essentially, you now have taken the money from the user but have no record of it in your database. Every billing-related operation should have some special logger that lets you know immediately when a rollback happens that affected the billing data.

Improving ng-repeat Performance with “track by”

| Comments

Probably one of the very first things you learned doing with Angular was how to use ngRepeat. It’s so easy and simple, you gotta love it. Here’s an example:

1
2
3
4
5
<ul class="tasks">
    <li ng-repeat="task in tasks" ng-class="{done: task.done}">
        {{task.id}}: {{task.title}}
    </li>
</ul>

The problem

Now say you have a button above that list to refresh it.

The obvious implementation for this refresh would be something along these lines in your controller:

1
$scope.tasks = newTasksFromTheServer;

This is a trivial piece of code, but it would cause ngRepeat to remove all li elements of existing tasks and create them again, which might be expensive (e.g. we have a lot of them or each li’s template is complex). That means a lot of DOM operations. That would make us sad pandas.

In something of a more real-world use case, where instead of our simple example template each task is its own directive, this might be very costly. A task directive that calculates a view model with even relatively simple operations like formatting dates is enough to make the refresh feel laggy. There’s a link to a fiddle with an example at the bottom of the post.

Why would Angular do this? Behind the scenes ngRepeat adds a $$hashKey property to each task to keep track of it. If you replace the original tasks with new tasks objects from the server, even if those are in fact totally identical to your original tasks, they won’t have the $$hashKey property and so ngRepeat won’t know they represent the same elements.

The annoying solution

The first solution that comes to mind to most developers is to not replace the whole $scope.tasks list, but update in place all the existing tasks objects with the data you received from the server. That would work because it means $$hashKey property would be left intact in the original objects.

But that’s not fun, is it? I hate surgically tinkering with objects, as it is error prone, less readable and a pain to maintain.

track by to the rescue

In Angular 1.2 a new addition was made to the syntax of ngRepeat: the amazingly awesome track by clause. It allows you to specify your own key for ngRepeat to identify objects by, instead of just generating unique IDs.

This means that you can change the above to be ng-repeat="task in tasks track by task.id" and since the ID would be the same in both your original tasks and the updated ones from the server – ngRepeat will know not to recreate the DOM elements and reuse them. Boom.

To get a better feel of the difference this makes, see this fiddle. By default it doesn’t use track by and the date formatting it does is enough to make clicking “Refresh” feel noticeably slow on my computer. Try adding the track by and see how it magically becomes instant, because the task directive’s link function is no longer called on each refresh.

It’s really that easy to get a quick little boost in performance that also saves you writing annoying code.

Writing More Maintainable Angular.js Directives

| Comments

Directives are, essentially, the most powerful building blocks we have in Angular, yet for beginners they are incredibly easy to get messed up.

Here are some guidelines that I’m pleased with, and that can help new comers. I would love any feedback from fellow coders!

My assumptions: The main problems I have in maintaining “magical” code are lack of explicitness and traceability. Explicitness means I would rather write a bit more code in order for it to be clearer what my intention was and what exactly I’m trying to use. Traceability is making an effort that from any piece of code it would be clear what it depends on or what depends on it. Even with thoroughly unit-tested code I believe the following extra steps are necessary.

Favor isolated-scope directives

I pretty quickly realized that what I should use about 90% of the time are isolated directives. These are directives that have a clean slate as a scope. Their scope is clear except for those bindings which are explicitly made in the directive’s definition:

1
2
3
4
5
6
7
8
9
app.directive('myDirective', function() {
    return {
        scope: {
            // The only properties visible in our scope from the parent scope:
            foo: '='
        },
        // ...
    };
});

The major win here is that never again will I be stuck with opening a directive and sifting through the different properties referenced, trying to understand what, if any, the directive is using from its parent. This means I can more safely and quickly refactor, change and delete code.

Explicitly passing dependencies with require

Let’s start with an example. Here is the screen for editing mailboxes on the iPhone:

This might have been written in Angular like so:

1
2
3
4
5
6
<div mailboxes>
  <div ng-repeat="mailbox in mailboxes" mailbox-line edit-context="editContext">
    <div mailbox-edit mailbox="mailbox" edit-context="editContext"></div>
    <div mailbox-description mailbox="mailbox"></div>
  </div>
</div>

In the above example editContext is wired through the mailboxLine directive even though it doesn’t care about it at all, just so it can pass it along to mailboxEdit. Once these extra wirings start getting popular in your app, sometimes across several levels deep just to pass some object, you won’t like it. Take my word for it.

What are you to do?

Requires to the rescue!

Angular’s directives have an amazing ability, though not as widely spread as it should be. A directive can require that other directives will be present either on the element it is placed, or in one of its parents:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
app.directive('mailboxEdit', function() {
    return {
        scope: {
            mailbox: '='
        },
        // We make sure the "mailboxes" directive is somewhere above us
        require: '^mailboxes',
        // "mailboxesCtrl" is the "mailboxes" directive's controller
        link: function(scope, element, attrs, mailboxesCtrl) {
            // Now we can use mailboxesCtrl.editContext
        }
    };
});

app.directive('mailboxes', function() {
    return {
        // Create a directive controller and expose the edit context in it
        controller: function($scope) {
            // Note we assign this to "this" and not "$scope"
            this.editContext = new EditContext();
        }
    };
});

As you can see above, using require means our directive can get a parent’s controller and reference it (mailboxesCtrl), as specified in the Angular docs here. The simpler HTML would now be:

1
2
3
4
5
6
<div mailboxes>
  <div ng-repeat="mailbox in mailboxes" mailbox-line>
    <div mailbox-edit mailbox="mailbox"></div>
    <div mailbox-description mailbox="mailbox"></div>
  </div>
</div>

This is awesome in so many ways:

  • No annoying wiring of things all the way down
  • require will throw an exception if the requirement fails, making it impossible to wire wrong
  • The nested directive explicitly tells us what it depends upon
  • The parent directive explicitly defines an exposed API

I find this way makes maintaining a large system a lot easier and more straightforward.

Please use hasOwnProperty: short story of a hack

| Comments

I know a lot of developers, when writing JavaScript, tend to neglect hasOwnProperty. I can understand it, too. First, it takes a lot of writing: compare if (foo.hasOwnProperty('bar')) to if (foo.bar). Also, some coders assume that if the object you’re handling is a simple object you created yourself and that you know it has no prototype inheritance, then hasOwnProperty is useless.

The problem is that hasOwnProperty is almost always relevant. As in 99% of the cases. So, why not make a habit of always using it? When you don’t, it can really bite you in the ass. Here’s a short story:

The story of a hack

I was helping a friend with his Node.js server. I happened to glance a little piece of code that was basically a cache of valid administration authentication keys. An approximation is:

1
2
3
4
5
6
7
8
9
10
11
12
var adminCache = {};
fetchAdminKeysFromDatabase().forEach(function(key) {
    adminCache[key] = true;
});

// ...

if (adminCache[request.getParameter('key')]) {
    // Assume the request is authenticated
} else {
    // Return 403
}

Seems legit, right? Well, maybe at first glance. But imagine what happens if an attacker passes in a key of "toString"? BOOM! Yes, it’s that easy to get pwned.

That’s because adminCache, like any other object, has a toString property. I can only imagine how many similar bugs are waiting out there because of this.

Of course, had the line been if (adminCache.hasOwnProperty(request.getParameter('key'))) everything would have been just fine.

So, please, use hasOwnProperty.

Frontend Driven Development

| Comments

For years, whenever I worked on a new feature I would first figure out the backend and get a rough implementation of the server side solution. Only then would I move on to the other parts.

I think this was because the backend is the part that does the heavy lifting. When you don’t start from the backend, it is easy to find yourself planning features that require way too much from the server. Therefore starting with the backend made sense.

For the past year or so I’ve been doing it backwards – getting the frontend roughly working first: Frontend Driven Development (I kinda hate myself for naming it this way, but I believe it gets the point across).

The Joy

This change brings about many interesting improvements to our feature development:

First, it means we start from a point that’s backend implementation agnostic. This way we focus on the right UX and flow before giving in to how technical difficulties and limitations. Some changes might be needed later, but I find it better to start design, pretending we have an “ideal world”.

Also, no matter how much design work has gone into a feature, a lot of changes and criticism would only appear once you have the UI almost done. When the team sees the feature it shoots off iterations that delay the deployment of the feature. With FDD the feature’s basic version is there to play with and tweak very early, and while the backend part is being implemented the iterations take place.

I saw designers and product people loving having a bit more time to play with the feature with less stress, since they got started with iterations earlier and didn’t hold up the feature from deployment.

Another advantage is that, usually, the frontend is the most flexible part of the system. Now you allow for more short & easy experiments, even those that are never fully implemented, without wasting time developing a backend that’ll never be used or that limits the experiments you make.

Why didn’t I do this earlier?

I believe it’s mainly because working on the frontend when the backend’s not there yet can be a pain. You either stub a lot of code in the frontend, or hard code dummy endpoints on the server, both of which are ugly and a PITA to maintain.

Several months ago we wrote a tool that allowed us to easily intercept requests and fake them whenever needed, and since then the FDD move just “clicked”.

Whatever your environment, be it web or mobile, I bet you can make sure working on the frontend disconnected from the backend is easier, and let your team get stuff done faster!

Happy coding!