Brad Frost wrote a very good post called "Primed and ready to go" on how developers can get working early on in a project, even if the design is not finished. I was nodding along, going "yes, yes, yes", but there were things about it that didn’t sit quite right with me.

Setting up infrastructure and generally starting to look ahead at what resources and tools will be needed to make the project run smoothly is a splendid idea. Anything that means developers are part of the project, part of the converstation is generally A Good Thing. Throwing stuff over the fence at the end is A Very Bad Thing, that cements the artificial line between design and development, as Brad points out in the post.

As I read it, I stumbled a bit over the following sentence:

Because boy there’s plenty of work that needs done: setting up Github repos, dev and production server setup, installing CMSs, setting up development tools, etc.

The bit that didn’t sit well with me is the "dev and production server setup, installing CMSs" part. I think I understand what Brad was trying to say, and he nuanced it a bit in the next paragraph – we can’t get coding on just anything straight away, but we need to pick some general problems. But that particular passage reminded me of a post by Rachel Andrew: "Stop solving problems you don’t yet have".

Depending on the project, you will have done more or less work in terms of concept, IA, flows and patterns before the phase that Brad describes in the post comes in. Unless you’ve done the research and nailed down the most important structures and user flows that help the project achieve its goals, you probably shouldn’t be choosing and installing/building a CMS.

Choosing how to work with front-end workflows is probably an easier choice to make. Are you delivering code to a client organization, or is your in-house team the ones who are going to maintain it? Is this a very large project or a smaller one? Things like that are mostly known beforehand, and can help you make good decisions on how to set up housekeeping and styleguides etc. But choosing a front-end framework or a CMS has lots to do with the direction of the design (design in a very general sense) can bite you in the ass if you’re not careful.

I think a lot of developers are very eager to get involved in projects. In our eagerness to contribute, we might make choices based on what technology we think is popular, cool or just plain fun to work with. Those are not unimportant factors, but the thing leading the choices of tech to build something should probably be more geared towards the nature of the thing rather than our preferences.

I suspect many sites are built as single-page apps, with massive JavaScript dependencies, not because that is the best choice but because someone was very eager to get started on "a project in X", where X is Backbone, Ember, Angular, Skunktrap, Toodle-Pip or Cumberbatch.

(Yes, I made some of those up.)

Anyway. These are nitpicky things. I want to nuance Brad’s post rather than criticize it. There’s still tons to do for a front-end dev in the early phases of a project. Just make sure you’re in the right phase of the project to solve each particular problem.