After you’ve built your database tables, in Yii (our PHP Framework of choice) you can actually just generate PHP model classes (and controllers and views) that represents that same data, but obviously in PHP.

If you’re reading this as a non-technical reader, this may get too advanced for you, but I’ll give you a quick overview. In the sort of applications these tutorials are written for (and the sort of application we build at FaceySpacey), the code is written according to an MVC (“Model View Controller”) architecture. The Yii Framework is based on this extremely popular pattern. The core concept to at least have a cursory understanding of here is that “models” represent your data in your database, “views” the templates that your web pages are based on, and “controllers” connect the whole thing together, making use of your models and triggering the display of models based on which URL your users visit.

Typically we won’t generate the controllers and views though as we have our own way of organizing them that’s a little against the Yii way, which we find allows us more flexibility and is standardized within our company.

Building/planning the technical architecture doesn’t stop however with the generation of some near empty shell model classes. What we’ll do next is group the layouts by controller and determine which pages our controllers will generate. The controllers generated by Yii’s CRUD (“CREATE, READ, UPDATE, DELETE”) generation tools will make a controller for each model. Often your app won’t need to allow users to create/edit/etc every single model (i.e. database table) you have in your system. For example, the “edit” table described in the previous tutorial doesn’t need a way for users to create, update or delete them. So for the models/tables that do have corresponding interfaces, we will however follow that Yii convention. For all the other pages, we’ll add them as empty shell “action methods” to a controller, whose name will logically represent all those pages. If you aren’t technical, this aspect of the speccing tutorial is probably going over your head. Generally speaking, the idea is just to assign the pages that you’re app will generate to specific code files, which technically in this case are called “controllers.”

We’ll then do the same for views. Again, we won’t follow the Yii way precisely. We’ll use their theming features and create all the views in a Theme, and organize the view files in a way that makes sense for them unrelated to the controller action methods that will trigger them. We’ll organize them in a way that a designer would think makes sense--since a designer will continue to work on them throughout the rest of the project. That way is specifically where similar layouts are grouped in the same folders, even if the layouts are from different areas of the application triggered by different controllers. We just find that not forcing your “view” files to match controllers makes it really easy to browse view files and jump between editing them. You do have to kind of switch gears a little more than if your views precisely paralleled your controllers, but we find that switch easy to make.

So either way, the idea up until now is we create basically empty files, title them properly, title some of the methods they contain, and arrange them according to a folder structure we plan to keep for a very long time.

The next bit is we’ll pinpoint problem areas, usually areas that require using 3rd party APIs and libraries, and stock the system with these tools so it’s there waiting for us. If we can, we’ll imagine our own client classes that use these tools, and again create and title empty files to represent them and put them in the appropriate place. Often when coding, you’ll be tempted to just stuff your models full of methods--right now is the time where we figure out our own components to build that model class methods can be clients of. So we’ll stuff our “components” and “extensions” folders with shell classes, just sitting there waiting to be flushed out as a reminder of what we need to build.

In short, your project’s file system becomes a to do list of what you have to code. That’s what this part of the tech speccing phase is all about. What this does is help developers see where everything is going to go. There are lots of decisions to be made here--for example if you’re going to bundle up part of your application into what’s called a “module” or a “widget.” So just the existence of these files are notes to developers saying how something should be coded.

Next we’ll set the configuration settings of the application so that all the 3rd party libraries are included, URLs are formatted in a beautiful way that will be consistent from the start, so the database is connected to the application, etc, etc. And then we’ll test developing a few things to make sure it all works as expected. What that means is we’ll make the application generate boring pages where all parts are used, i.e. the controllers, views and models, and make sure everything is working as expected.

If there are some particularly scary parts, developers should start working on them asap before all the final decisions for the product are sealed to make sure you will be able to do it. Basically send out some scouts into the most complex areas of the application and have them work on it as soon as you can. As I said before, there will be overlap between the product and tech speccing stage. As soon as the tech speccing stage is far enough long that you can start building the file system just described, get some developers experimenting with coding the hardest parts to make sure you’ve made some of the right decisions. You’ll inevitably find that some things take so much time to code properly that it will be a big time saver to back-track and change the product (and redesign it).

The final aspect in this phase is that we’ll create sub-tasks to the product tasks in Fogbugz. Obviously these sub-tasks (and often sub-sub tasks and so on) are of a technical nature. If there are overarching technical tasks that don’t apply to a specific product area (i.e. page) or perhaps apply to many pages, we’ll create “areas” for these “technical spikes.” This whole phase was about finding the problem areas in the technology. So when we find them, we need to document them not just through the organization of the file system, but as Fogbugz cases/tasks. In short, we’ll add all the technical tasks we can to the product tasks in fogbugz, and intertwine them in a logical way. If we can associate them directly with product tasks and pages, we will, and if not we’ll create new areas that group a set of related technical tasks.