New Projects, and how to handle the juggling act that ensues.

Today marks yet another year in which I've been aboard this mortal coil as it circles our solar system's centre point. So as I sit here watching to see if the remake of 'The Day the Earth Stood Still" is a much of a car wreck as has been stated and re-stated for the past few months, or if it will end up being one of those guilty pleasures. More so on to the point of this most recent update:

We in the United States of America are currently experiencing a rather nasty economic downturn/recession due to unregulated mismanagement of the country over the past many years and as such are having (as a country) to deal with roughly one in every nine persons of working age being unemployed. Yet in all of this unfortunate turmoil as brought about by the economic calamity, I find myself inundated with more simultaneous clients and projects than ever.

While I have managed multiple projects before, it was usually with the benefit of a staff. In this instance I find myself as the sole Engineer on the job. I enjoy being the centre of a given project, especially focused projects with clear requirements as they encompass the most fluidity in terms of project and process flow beginning to end. In this case however, due to a recent spate of decisions by several key individuals in charge of my various client entities, there has been an influx of new projects, primarily new ventures and re-launched (and recently acquired) web entities.

These are all primarily fashion and lifestyle media groups and magazines and while they all have a similar bent to them, the amount of design behind the scenes differs greatly from one entity to another. I find that the sites in which there is a solid plan are to most enjoyable on which to work because this is a start, middle and end whereas projects lacking any real direction simply waste a considerable amount of time, effort and never seem to measure up to properly designed sites.

There are several major concerns here when juggling this many projects, but thankfully there are just as many solutions:

Problem #1: Keeping focused on a specific code base.

Solution #1: Thanks to the beauty of multi-windowed environments, comments and code versioning systems such as Mercurial (Hg), Subversion or Git, we can save our place, with comments and safely return to them at a later time with notes on where we left off. A bigger part of the solution here is a proper code editor that focuses on all elements of a project in a shelf or sub window. By utilising an editor of this type (such as TextMate for OS X), we can keep one window open for each contracted project, each with its own attached drawer and as such simply minimising a given window completely puts a specific project out of sight and out of mind.

Problem #2: Estimations and management of many projects for multiple clients.

Solution #2: Give only rough estimates and keep in mind any potential work which may or may not come into the fray. There is also an amazing tool which only requires a writing surface and the appropriate complimentary writing implement (paper & pencil, whiteboard and a dry erase marker, etc.) The infamous GANTT chart, which allows for a wonderful representation of project portions/phases and time phases. One should not be afraid to over-estimate their time frames for a given project and/or portion of a project. One bit of wisdom which was learned after having it repeatedly played out by both myself and others is that men (not as much as on the women's side of the equation) generally underestimate by a factor of 3. If it is assume that a guy honestly believes that a project with take x minutes, in reality the time frame would be closer to x³ minutes. Gauge oneself over time and projects and adjust the factor accordingly, however start with the aforementioned suggestion as it has proven accurate in my experiences and that of others whom I know personally and professionally.

Problem #3: How should one handle priority requests and/or 'must dos' such as time sensitive changes or additions necessary to client business function regardless of assumed actual worth/priority.

Solution #3: This is much simpler than one would expect. When discussing the issue with the client (wether internal (if a salaried employee and dealing with internal 'customers') or external) point out that this will be shifting the entire project timeline by the time required to complete this unscheduled emergency. Now this isn't always practical or appropriate such as in situations in which a previously scheduled change was turned into a 'must do'. In situations such as these that portion of the scheduled project can be removed from ones GANTT (or other scheduling) chart(s) it their entirety.

There is one caveat with this approach; when removing a project portion due to unexpected/unplanned rushed completion, always add in additional time when shifting the remaining pieces of the project(s). The primary reason for this is simply because additional time should be made available regression testing and/or additional testing due to the reduced time frame and unscheduled manner in which said changes were made, one in which a great possibility for error introduction was more likely. The other major reason for doing as such is simply to protect oneself when another one of these situations occur. It would be foolish for anyone to think that if this happens once, that it is unlikely to occur again. Generally there are those who have little emergencies all the time, and those who 'suffer' from such events rarely if ever. If it happens once, be sure to assume it will occur again as it is usually the result of bad planning or communication somewhere between the engineer and the end customer though more oft than not it is a middle-manager or a sales person making promises which had they been honest and/or considerate of others, they wouldn't have made in the first place.

Handling multiple projects can be easy if one enforces certain rules (albeit with a willingness to bend as long as attention is paid to making adjustments so as to not allow oneself to be run into the ground by continually pushing more amounts of work into a time frame never intended for said work as such.). The importance of communication is key in this instance as expressing realistic time frames in the first place would resolve many of the ugly situation which sadly arise in real world environments on an ongoing basis.

Django and Gantt Charts

It has now been almost a full week since I started the complete inkedmag.com site and infrastructure redesign in Python using the Django web publishing framework on FreeBSD, and I am happy to report that it is awesome. Mind you we're talking version .96 of the product, yet it truly is a dream with which to work.

I only recently started working with (and writing about) Cheetah, a wonderful python template engine, and had to very quickly learn yet another (Django's own template system). I must admit that Cheetah is easier to ready and learn quickly, but Django's system is considerably more agile in terms of conditionals and modifiers inside the template itself. There even happens to be a simple mechanism for cycling through a list continually changing on each iteration of the loop within which the cycle conditional resides. Simply put, it is wonderful for automatically changing the background colour of a row in a list.

For those unfamiliar with Django, it is simply one of the better web frameworks for content publishing on the web these days. While learning curve can be a little steep for some pieces of the framework, as a whole the speed at which once can produce working pages and applications is staggering. The ease and elegance of the system truly makes one enjoying creating new applications within the framework.

The first application I chose to migrate from native python into the framework was a simple store locator. The new version not only is considerably less lines of code, the database management was done for me at application creation/initialisation. I then simply exported the data from my existing application and imported it into the new table(s) Django created.

I could go on waxing poetic about every little bell and whistle, but I'd just be paraphrasing what many others have already pointed out online and otherwise. Don't think of it as Ruby on Rails because it isn't, though that isn't to be taken as an insult to Ruby. It is much more focused, cleaner and far simpler to setup and get running, including all of its own admin interfaces for the applications you create, as well as its own standalone development web server. Check it out, you won't be disappointed. This is going to save me a considerable amount of time.

Which brings me to my second point; Gantt charts. They are simply not something I find myself utilising on any regular basis, though I think that is going to change. I'm my own boss and have found that gantt charts produce the easiest visual way to show people the various pieces necessary for a project, when each portion can be expected to start and finish, all in parallel with the other projects for which I'm responsible (and/or coordinating).

I feel that the use of this tool more than others really gives a great method by which to see which projects will take the bulk of the time, and what projects overlap, etc. We have a system rewrite to produce and a whole server to replace, not to mention migrating certain custom software into the framework all before the new year. This is doable, but only because we've clearly set realistic (though tight nonetheless) goals and time frames. Consider using a gantt chart if you have more than one project or component of a project which needs to be done in a given time frame. Use one if you need to share with one or more people your schedule and need them to understand as quickly and clearly as possible that with which you are juggling or dealing. You find yourself quickly addicted to its usability.