Did you know FaceySpacey is the creator of Redux-First Router and Universal?

The Startup Incubator.
Your one stop social media shop
Speccing
There are several schools of thought when it comes to how much you pre-plan your application and how much your developers develop it with agility, i.e. according to so-called “agile” practices. Our take is that “Agile” has been misinterpreted by many a failed startup as an excuse to operate without a proper plan.
However it goes deeper than that: we believe there are different best practices depending on the scenario. If you’re a funded startup (i.e. with funding in the millions), you have the luxury of refining an iterative process where you explore what you want to develop in small steps. For new startups, this is a costly phase where you figure out your development process. So if you only have $50k-150k for your project, you’re in a completely different boat, and you simply cannot afford that. You have to operate completely differently. We believe it boils down to 1 thing you absolutely must do differently: completely plan what you will get for your $50-150k. This means you means you must know exactly what you plan to launch to the public in your initial offering. And this requires a greater degree of what has been often, and pejoratively, called “crystal ball” planning. This is where we excel.
This is how we do it:
SCOPE OPTIMIZATION
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.
LAYOUTS
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.
WRITTEN ORGANIZED SPECS
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.
DATABASE & APPLICATION DESIGN
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.
RHYTHM & TESTING
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.
FaceySpacey Speccing Resources & Tutorials
Testimonials
Refer A Friend
