I'm more interested to know the actual technical details of the build and testing process than the "Task-List" software development based approach because that can be done by any software project management tools (even JIRA).<p>What's missing in this article is the whole Continuous Delivery technical aspect of it.<p>What do you guys use to build the NodeJS app?<p>What do you guys use to test the NodeJS app?<p>What do you guys use to check the code coverage of the NodeJS app?<p>What do you guys use to test the front-end?<p>What is the automated testing strategy?<p>How do you store artifacts of builds, schema migration (if using RDBMS) or handle different model versions, how do you rollback (what's the rollback strategy)?
Fog Creek are the _kings and queens_ of dogfooding. Spolsky, you sure have nurtured a group of very loyal team players. I applaud you all. It must be really nice to work at a place where the love of the process and the product are both so strong.<p>In my opinion if there's one thing a reader should take away from this it should be that Single Page Apps and separation of server and client are The. Best. Thing. Ever. From the start, design your system this way.<p>Good post, and an entertaining read.
> > The Trello API is well-written, has no bugs, and is totally rock solid. Or at
> least it doesn't change very often. That means we can put out new
> clients all the time without having to update the API. In fact, we can have
> multiple versions of the website out at any given time.]<p>A very counter-intuitive result: most people would not consider a stable API to let you iterate quickly!
I've used Trello & FogBugz over the years and we've even modeled some of our software after some of the practices they've written about. Amazing stuff!
So they create a new branch for each fix? And all developers are supposed to merge in their branch every few hours or so? Isn't it a bit of a drag?
What I'm interested in is the mechanics behind how they know were to send a user based on their channel (beta/stable/alpha). We wanted to do something like this, but we couldn't figure out how to route users to the right app server either using AWS ELBs or nginx proxying ... admittedly we didn't really spend a lot of time thinking about it though.
I'd love to hear—maybe I missed another blog post—why they went with the single release manager, where only one person can merge and deploy. What happens if Doug is sick or on vacation? Or even just in a meeting? What is a typical amount of time for a change to sit in "ready for merge" or merged but not deployed?
Does anyone know how the server determines which channel the client should be using? Are they doing this check at the apache/nginx level, or on the server right after the user is authenticated, and before the client code is sent?
This is great and all, but I really wish I knew why they won't make the audit logs accessible to users. If someone has a hack for this, I'm all ears.<p>Need it for compliance documentation.
> The Trello API is well-written, has no bugs, and is totally rock solid.<p>The no bugs claim indicates to me this wasn't written by a technical person. Or at least, not very technical.