We keep the scope small, but quite a bit larger than what you’d get with one iteration which ultimately wouldn’t be what you feel is suitable to launch to the public--ideally down to what a multi-million dollar startup might accomplish in about 10 small iterations/sprints. In short, we determine the concise set of features that capture the essence of how you want to present to the public, and make sure not to waste any energy resources going farther than absolutely necessary.

We produce layouts (and full designs in combination with a simultaneously running branding phase) of every page of your application, and every state each page can be in. the imagining of these layouts is what we do best. It’s where we explore deep into what you’re app could and should be. Other shops have to build lots of potentially useless stuff in order to see how far into the future we can, and not to mention waste lots of money during this exploration and process refinement phase. With FaceySpacey you can look at your entire application before a single line of code is coded, and know exactly what you’re going to get.

This is simple once the layouts are produced. On a per page basis (and per state basis), we create written specs closely attached to the layouts, and organize these feature requests in FogBugz, Joel Spolsky’s project management software. Again, the key here is that the list of tasks are coupled to their layouts, and then that FogBugz is arranged in a way to mirror this association. Other shops may do more of a Bottom Up approach, where specs are written in association with the underlying data structures. We find the problem with that approach in $50-150k contract projects is that you, our client, can’t closely associate the tasks being executed to precise features you’re looking to see. For example, a database structure may be prepared and it took the developers a week to do, but you, as an end user testing the system, will have no way to associate the completed tasks to completed features you can use, and then you have no idea what you’re developers were doing during that time. In other words, we’ve optimized our process so at all times you know what’s going on in the form of testable features.

First off, by “design” we’re referring to the planning of the underlying architecture. Just because we focus on a Top Down approach, where the specs and “product” lead the way, does not mean we also--simultaneously--take a Bottom Up approach. The difference is that before each decision we make for the underlying architecture, we have a precise product goal in mind we’re working to achieve. So in this part of our speccing process, we’ll come up with the entire database design--that always happens. Then we’ll prepare empty code files for all the code we anticipate building. Lastly, we’ll pinpoint potentially problematic areas in the application, and discuss and write a plan for how we will address them when we get to them. This way the entire plan isn’t thrown off track when we find a major challenge deep in the app that changes the way tons of other stuff should have been coded, or even the way other features should have been. The key here is that we do the tech speccing in conjunction with the product speccing. We continue to refine the product spec all the way until the tech spec is done. The result at times may be that we slim back some features or slightly change them, but specifically in a way that maximizes the product goal in proportion to the time it takes to develop.

Typically called “sprints,” we establish predictable rhythm of execution through which you know when to expect results. The type of applications we do (to start) are medium-small applications that capture the precise minimal viable product you need. Therefore, we can do our sprints in increments of week at a time, rather than larger increments common to desktop applications of yesteryear. This insures you feel the pace at which we’re going from the start, and everyone can gauge progress, and accordingly feel comfortable with the process every step of the way. Starting on Thursday until Monday morning, you in conjunction with our dedicated testers test the application. Teams without dedicated testers are wasting your money by having highly expensive engineers be solely responsible for testing, and waste your time by putting the responsibility completely on you, somebody just getting acquainted with our process. The final point here is we do not move to new features until the current features work perfectly. The reason is simple: fixing bugs later when coders are less familiar with the code at hand takes many times longer to fix than fixing it right when they first made it.