8bitOrange

Nerd Post: Planning…planning…planning

I had a friend post on twitter the following:

The problem with so much pre-planning and documentation is that the moment you start actually making, it’s no longer accurate. Time wasted.

Now I agree with him somewhat, but I recently began running projects here at UCF, and my team is small, and somewhat under experienced. The project was a sort of single login system for all of the staff in our college to be able to manage anything from web tickets/new projects, Help Desk tickets, Asset Management and even CMS for their departments sites. This was a big undertaking and when it began I stressed the need for planning, and a lot of it. The first was a debate over technologies. We wanted to push forward into HTML5, and heavy use of javascript, great, the problem was that our users are all using IE7. They will be moving to 8 soon, but none of them will, by default, be using Firefox or Chrome and we know it. So we had to come up with some solutions, we spent a couple of weeks working out demos and getting stats on what we could use and what we couldn’t. We learned a good bit and moved on.

Next part of planning was how we were going to build this. To say that this place was not set up for heavy code work, is an understatement. So I had to then put some standards in place. We moved into a Debian server, wrote up some PHP documentation and some JS documentation on how we would write it, set up a code repository (SVN, which I’m now regretting and thinking of switching to Git due to a couple of headaches we hit within the first two weeks), and got to work…planning.

So how planning really started was this, we (me, two developers, our designer and our work study) sat in the conference room with pencils and paper and literally drew up how we thought the “portal” would work. We all had to demonstrate with a pencil how you would navigate through the site and how it would work. It was interesting and taught us a lot of how we all think. We group voted on the best solutions from each of our versions and mashed them into one site. After that we set out on our needs, heavy use of a strong ACL system, a good quick deployable UI including a useful but extendable js library.

So then we went into what I like to call active planning. One of my developers who is basically our designer, was set to task on creating the HTML/CSS for the entire portal. Allowing us to quickly apply some classes and such and have our UI work, immediately with little to no work on our part. I don’t want to have to redesign a table everytime we put it together. I want to be able to put a table on it and call it “index” and have it look the way it should, and he’s wrapping that part up now, and it looks great and works well. No photoshop was used, he literally did all of his design work in HTML/CSS, which was gratifying to know that we don’t have to now figure out how to cut up a PS file, we have a working version of code that can be applied.

Then I wanted a JS library, that extends jQuery (our favorite framework) that could sit in our UI plugin and quickly be called and used without interfering with our structure. I don’t want to have to be doing custom js to pop up a modal window at any point. I want to say $.modal(‘type’, ‘message’) and move on. We have that now and it is great.

Last we planned how we want our DB structures to work and how we want to move from app development to deployment. We sketched it out on paper and have it in writing now.

We are now about 2 - 3 months into dev with a team of 3 and are getting ready to deploy the user system that backs every application we will be putting on top of it. I think if we hadn’t done the planning we would be trying to reconfigure every app we build, instead with the planning we have a stable UI, a solid user system for each and every app we build, which should make each of our app deployments quicker and less buggy.

I guess time will tell, but I am all for documentation, planning and process building. Without it, especially with a relatively young and tiny team, I think I would be setting myself up for disaster and a horrid rebuild cycle. Now different teams mean different processes, sometimes, scratch that, most of the time I think meetings are entirely unnecessary and hardly improve morale or productivity, but then again, some places work having meetings. To each their own and some may think my level of planning is under done, who knows. At the end of the day I think you assess where you are, assess your teams abilities and move forward with the best set of processes for you.