A Development Method: Front-To-Back, Simple First.

So, I'm working on a website for someone that is making use of GenericMVC, a small MVC based framework that I'm developing (slowly, and badly at first) just so that I can get my head around the concept of MVC... anyway, all of this has given rise to some level of introspection, meaning that I have, in spite of my supposed concentration on the code, discovered and analysed my working style.

Future employers, please stop reading now, I might embarress myself :P

Allow me to intoduce you to my working method; Front-to-Back, Simple First. As I start my work, I tend to have an idea of what I need to do. Either I'm working from a spec-sheet or I have in my head a goal for which to aim. Of this, I then have a compartmentalised vision of each part of the project fit snugly together, knowing how they might talk already. I then take them and arrange them in order of simplicity. Once I have this order sorted out, I will then begin to hash out my code. This takes care of the 'Simple First' part of my method, so where does 'Front-to-Back'come from?

Quite simply, it refers to systems from the perspective of interface, either user or other systems. I will work from the systems at the front, things like a relatively static page on a website, all the way through to the back, meaning things like database relationship traversal or image pre-generation.

Imagine all of the above working in some sort of heirachal grid. The top or front of the grid is the code/coder-facing parts, meaning function, class and similar definiton. Following this, we find user-facing parts. In the case of GenericMVC and the website I'm working on, this is error messages, templating systems and the web-pages themselves. Being a UI nut, I do prefer to have my UI squared away at the eariest opportunity, or at least as done as possible as soon as can be. Following this, we have a stage of code optimisation, because it's always fun, before focusing on Admin-facing code, further code optimisation, ending with a good lump of sit-down, take-notes testing to complement that which has gone before.

On this same grid, starting on the left, we have the simple tasks. Static pages, menus, that ilk. To it's right, more complex stuff, like an article directory, a list of things. Nice simple stuff with a bit of a think to it. To the right again, more complex stuff. An image gallery, a user system. Further again, we have a fully fledged forum and all that jazz, ad nauseum.

This all has certain advantages; if you are working on systems alone, you have an idea of what things need doing, how easy the various things are, and roughly what order you want to do things in. This is great, because it means that you have a way of measuring your own progress, something that I love to feel pass by. Feeling stuck? Can't make your head work the right way? Just wander off and find one of the easier tasks to do.

This does, of course, have disadvantages; It's not going to work well in a team environment without planning. People will have different ideas on what is simple or not, what the order of code-depth ought to be, or even on how the project ought to be split up into units. I'm sure you'll be able to adapt it for team-work, but I've never tried. If you do, let me know how it goes :)

Oh, and if you're wondering about Gnome-Do? It's awesome, obviously :)