To give some context, I've been a Ruby & Rails developer for the past few years, and just recently started doing quite a lot of JavaScript to add more responsiveness to the apps.

When programming backend, it is quite easy (at least for me), to do most of the stuff test driven and just keep hammering out a bunch of code that works, while being able to focus.

But I found that as I'm moving more towards the frontend, I am constantly context switching. Some JavaScript is easy to test (models), but the parts that are directly connected to the GUI seem just impossible to reasonably test automatically.

This isn't as much of a deal when I first start with the GUI part with dummy data, but once it all gets connected, and the GUI is created based on data from a an external API and my machine is running two apps at the same time and I'm basically debugging both, it just seems like I'm constantly context switching, not really being able to focus on one thing.

An example here might be a Node.js chat server that connects to another Rails application via some API. Now if the API was already done and set in stone, I could easily just focus on the Node.js part ... but trying to do the whole thing in some agile fashion, I just built the API as I build the Node.js app, which has a side effect on working on both Rails and Node (both backed up by different databases etc, ...).

If I compare this to working on one small library or just some deep backend stuff, I find that my productivity basically non-existent, because I constantly switch around and find bugs in 50 different places, instead of just focusing on one.

Is there something that I'm fundamentaly doing wrong?

2 Answers 2


If you don't want to context switch you should hand GUI development to someone else.

The problem you are having is pretty common if the front-end and back-end of a system is developed by the same person.

Also if you had all the requirement specifications, it would be easier to develop both parts separately, but of course you are talking about agile development.

  • "Also if you had all the requirement specifications, it would be easier to develop both parts separately, but of course you are talking about agile development." +1
    – Giorgio
    Nov 8, 2014 at 15:16
  • 1
    Wait, what? Agile is orthogonal to separation of concerns. Yes, specs would help focusing on one part. But sorry, this has nothing to do with agile (anyway the rest of the answer is accurate).
    – user44761
    Nov 8, 2014 at 20:28
  • Agile does have requirements - lots of them, and continually changing but at any given point of development you have a fixed specification you are supposed to be achieving. Lacking a story or task or ticket to complete isn't agile, its aimless hacking.
    – gbjbaanb
    Feb 10, 2016 at 10:43

There's nothing wrong with sitting down, thinking about what you will need, developing the API for this, then developing the GUI to consume that API. If you find your API is deficient whilst developing then you didn't think about the overall system well enough. You could go back to the API and add the missing bit and then return where you were in the GUI development... but that's exactly the problem. Instead, when you find a deficiency live with it and leave the GUI with a hole, when you have enough holes you then return to update the API (as in a 2nd version) and then begin to fill in the missing parts of the GUI. As you did some design work up-front the holes should be minor.

Think of the API as something that needs to be released before it can be used, then you cannot update it at will, you'll develop some discipline in design work.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.