Recently I was trying to get an installation updated as well as some of the plugins. What should have been a straightforward task, turned out to be several hours of messing around with permissions and trying to figure out why even 777 isn’t enough for the updates to NOT fail and what user should own what.

Well it turns out that it’s only partly the fault of WordPress as it is an issue with the FTP server. Still some better messaging would be helpful…

There were mentions about a patch and fixes in potentially in the 3.2 WP version related to the error I was getting:

Could not copy file.: /public_html/wp-admin/css/theme-editor.dev.css

However only after stumbling across this page I found an easy and quick solution.

Turns out it was enough to just switch from Pure-FTPD to Pro-FTPD.

For a long while my Windows 7 install inside VMWare 7 would get stuck at “expanding files 0%”. I kept thinking it was my machine and setup that was causing issue, after all a x64 tablet pc is not your most common config. Just in case anyone is curious I’ve got a Thinkpad x201t.

After trying both 32bit and 64bit Windows 7 version, upgrading my RAM from 4GB to 8GB and trying out changing the virtual disk location from ntfs to ext3 and back I was quickly running out of options.

Unfortunately VMWare support is extremely picky about your os versions and didn’t even try to suggest anything unless I downgraded to OpenSuse 11.2 – which was not an option due to certain driver compatibility.

Fortunately I decided to give it one more go and instead of using my external dvd drive for the Windows 7 installation I saved the DVD as iso and run the installation that way. And there you go, that was the solution!

My suspicion was the fact that my DVD drive is usb powered, however while looking for a solution I saw similar questions being asked for other linux hosts and no mention of external DVD drives, so it might be a more generic issue.

When setting a time before 1972 – this is 1970 and 1971 the time part will not be shifted in the UK locale as DST was only introduced in 1972!

This means if you are only calculating times and need the appropriate time adjustment you will need to set a date as no date part in Zend_Date means 1st Jan 1970.

Strong Ownership Definition

The whole concept is based on some users being predisposed to undertake certain work more than others. I mostly concentrate on project ownership and knowledge about it, however the concept does also acknowledge different skill levels between various employees.

The idea is best suited for agency environments where there always is a certain base of projects requiring maintenance work, as well as new clients. As over time employees come and go some projects can be left orphaned, especially if the maintenance is not ongoing, but rather tends to come back say every year or two.

Let us assume we have 3 employees at an agency called A, B, and C of similar skill level. We have the following 4 projects that need some work done:

• P1 – built by A
• P2 – new project
• P3 – project worked on by B and C
• P4 – old project none of employees built nor worked on

The simplest application of the Strong Ownership List would suggest the following:

P1 – A is a strong owner

P2 – A, B or C can be assigned as strong owners based on skill and availability

P3 – B and C are strong owners

P4 – again any of the employees can be assigned, depending on the circumstances this can be either strong or weak ownership

The specifics of these will be discussed in further detail later on.

Now the Strong Owner status gives that person the responsibility over the project. It does not necessarily mean that A will do 100% of work on P1, but he would be expected to be aware of were the project is at and be able to point for example B or C in the right direction if they are assigned to complete a task on P1.

Why Do We Need Ownership

Before we go into any further details we should establish why do we need project ownership in the first place. Considering our hypothetical A, B, and C are equally skilled they should be equally well suited for the job… If only life was that simple.

An often overlooked part of development is the setup time. This is even before we touch on things like “getting into the zone”. However the project is managed, be it subversion or ftp connection, the person undertaking the work needs to obtain all or some of the files and setup their environment. Passwords need to be found, as well as connection details.

Next there is the brief. An employee familiar with the project is able to understand the problem quicker, while a newcomer will need a full description of the project, where the problem is, how something should behave, and so on. Certain things will be obvious to a project owner, while for any random worker they might not only be harder to grasp, but there is also the chance they might be misunderstood.

Knowing the client can be another good point. And it does not matter if you just dealt with them via email, or had a hundred meetings in person. While working on a project a certain kind of rapport is developed that helps the employee better understand the client’s expectations and apply the most suitable solution for that particular client-project combination. This can be crucial, as the same project under a different client could have a totally different take at things. In this sense a random employee would not have the benefit of this insight resulting in longer communication, client frustration at being misunderstood, or even worse delivery of something not matching the clients requirements.

More Than One Strong Owner

I probably have not mentioned this previously, but Strong Ownership is not exclusive, a project can (and probably should have – more on this later) more than one Strong Owner. One person could possibly take a more leading role.

Just like in the P2 example when more than one employee is involved in a project and they gain similar level of experience relevant to it by working together, they would both become Strong Owners. However when for example B has done 80% of the work, while C has been doing some ad hoc support on the project under B‘s direction, then B would become a Strong Owner. Depending on the level of involvement C could possibly be a Weak Owner.

Weak Ownership

One might be tempted to think of it as the opposite of Strong Ownership, however it is more of a lesser version of it. Consider the following order:

1. Strong Ownership
2. Weak Ownership
3. No Ownership

Weak Ownership is the intermediate step between a person not being involved in a project and a person who is responsible for one.

Ownership Of a New project

It is all great in theory, but let us have a look at some concrete examples. To start of, an easy case – a new project needs to be allocated to a developer (or developers).

A, B, and C might have equal skill level, but they are all individuals. This said here is a list of things a project manager might consider when deciding who to assign:

• Employee availability and other project workload
• Previous experience with the client on a different project
• Previous experience with a similar project
• Personal preference (A likes Content Management Systems, B is fond of ecommerce, and C would love to do some ActionScript…)
• Overall worker experience depending on project complexity
• Employee skill level (we assume A, B, and C are equal, but in real life differences are inevitable)
• Number of already Strongly Owned projects

These are just some examples, and the list could go on.

The last point on the list is not crucial, but is a good reminder about even resource allocation. Just as you do not want all projects to depend on one person, you do not want every one to do everything, more on this later.

Ownership Of an Old Project

By old projects I am referring to the orphans briefly mentioned at the beginning. These are the unwanted and dreaded projects that probably no one has a clue about. Usually they just get bounced around like a hot potato no one wants to deal with.

The above list used for new project assignment could probably be a good start guideline for who to give the ownership to. As long as the employee matches the skill set required for the job it is down to more prosaic dilemmas like who actually has time to do the work.

Old projects are also similar to projects with a single Strong owner, who leaves, and no Weak Owners. The difference in such situation is that contrary to already abandoned projects the later situation can be handled by for example a properly done handover, which would create at least Weak Owners or in best case a new Strong Owner.

Solving the Isolation Problem

As the comment that prompted me to write this post mentions, an employee in charge of a project leaving the company can cause quite a stir and create orphaned projects. However this assumes that at all times the Strong Ownership List approach is used in its strictest form and with one Strong Owner per project.

In this sense the method could lead to work being highly dependent on certain individuals. The trick is to apply the system based on task urgency and complexity.

What I mean is say there is a small change to be made, that does not necessarily require massive knowledge of the projects structure, neither does it affect any processes in it. In such case if the project manager is willing to “sacrifice” the extra cost of initial environment setup for a No Ownership employee, then it is a good way to slowly “promote” a worker up the ownership ladder.

Obviously this requires the project managers to do cost weighting. It doesn’t necessarily have to be restricted to simple tasks. Depending on time and budget one of the two approaches can be taken considering we have a Strong Owner A and a Weak or No Owner B.

Advised and let go – where A (possibly together with a PM) does the initial brief to B, possibly outlining steps that need to be taken, hinting at the best approach etc. After this B goes of and does the work himself, possibly consulting with A in case of problems. This assumes B can spend the extra time on the task without straining the budget.

Shadowing – if the task is urgent but B is allowed to spend some time on learning how the project works A can do the work while being shadowed by B. This could be especially worthwhile with complex systems, as extra comments can be passed about the projects inner workings while the task is done. This means the work is done at the altogether quicker speed however either the learners cost needs to be either forfeited or passed on to the client.

The Ideal World vs Agency Work

The above might streight get some people saying – “but there never is time!”. And in some way you would be right. Learning processes always come at a cost, and it is a sad reality that very often this is overlooked by project managers or even higher superiors.

The bottom line would be comparing two costs (or three as we will see in a moment). Does the cost of using one of the above methods of preventing project isolation outhweight the cost of training someone up as part of a handover period. This should be part of more long term thinking on the side of project managers, and at the end of the day it is up to them to choose between short or long term gain.

The third cost to campare against can be the result of too many short term solutions. We assume above that a proper handover is done when an employee decides to move on for one reason or another. Unfortunately sometimes instead of passing on their knowledge they could be kept involved in current matters almost up till the end of their term.

Again it is down to a sort of greediness. Training takes time away from two employees – both the trainer and the trainee. While in the long run it definitelly will pay off to perform a proper hand over if project managers are more focused on finalizing current tasks it can lead to them overlooking that long term benefit.

Obviously you do tend to repeat certain pieces of code over and over in a project, but a framework? Behind a word like that usually stands a complex set of predefined elements. Though solid and reliable, these are often not very flexible and not easily modifiable. And the last two features seem to be crucial for projects that involve html and css.

Deciding to Use a Grid System

It all started with the plan to redesign the ThinkSentient website. I whipped up a new, more elegant design. It wasn’t done using a grid or any vertical rhythm (other than going for the “feels good” approach). This lead to the idea of updating the look of the ThinkRobot blog, considering that both websites are intentionally very similar with only a different colour scheme.

The problems started when I was adding the extra pages for blog specific stuff. Unfortunately I have not realized that in Fireworks (CS4) when you move guides on one page they do not affect guides on another, while state changes do. And I found out only after ending up with over 7 pages with guides all over the place. Sigh.

I had no choice, I would need to reorder most of these pages, as one of the side effects of wondering guide lines was a sidebar of different widths. So I said to myself, might as well give that grid thing a try if I have to do all this work over again.

Choosing the Grid System

Personally I decided to go with the 960 Grid System – the 12 column variation. Due to the recent decision of finally ditching designing for 800×600 I wanted a framework that was suited for the 1024×768 resolution, and the wider the better. 960 is a good, easily divisible number, just as the official website claims.

Secondly I preferred something lightweight and easy to tweak, with not too many defaults. 960 combined with Eric Meyer’s CSS Reset Reloaded was the ideal solution for me.

Grid vs Non-Grid

Design Without Grid

[caption class="img2" id="attachment_23" align="alignleft" width="300" caption="Design With Grid"][/caption]

The comparison above should show the slight differences. On the left is the design without a grid and vertical rhythm, while on the right there is the updated version based on 960 grid system and 18px lines. Some parts of the preview might vary, as the grid screenshot is closer to the finished design, however you can definitely see the difference a grid, and especially the introduction of vertical rhythm can make.

At some point we tried to introduce project ownership. This unfortunately gets a bit problematic when you hit the projects that no one has any clue about and the original developer has left ages ago (or it can even be unclear who the original developer was!). It does mean that someone eventually will know something about the orphaned projects once they take responsibility for them. Though again in case that person moves on, the situation will start over.

Why should you even bother?

The idea of a “strong ownership list” came to me when I was looking at one of the fellow developers struggling with a change on one of my projects. Most people in the office have a few projects they have worked on pretty much exclusively. In this sense it makes no sense to get a random person to work on a change, as you lose out straight away just because, they need to gain access to the project, possibly download a copy of the website to their computer (for example subversioned projects…), get their head around the problem if it is something more complex than a text change, etc.

The difference is even more obvious when the owner already has everything set up (personally I do not remove my older projects from my workspace), thus removing the whole preparation cost. Also because of the familiarity with the project time savings can also be made at the stage of making the changes. You know the file structure, you know how objects interact, how templates are set up, so on and so forth. It might not always be the case, depending what exactly the change is, but it is a risk a project manager might be unnecessarily taking.

The benefits of strong ownership

This way we get back to the “strong ownership” approach. If the cost difference (say in time spent on the work) is negligible between worker A (the author) and worker B (any random developer), than the ownership would not be strong, and can be ignored for planning purposes. The same goes for a project without an owner at all – the preparation cost for any developer would be similar, the only difference possibly being developer skills, which is not a concern in this discussion. However when a a project (or the change to a project) is complex enough for the difference between assigning it to worker A rather than worker B to be significant, than applying a strong ownership list approach will save both time and frustration.

There is also one more benefit of applying the fore mentioned strategy. Under pressure of time, a developer unfamiliar with the project might tend to produce a solution which would not be optimal for the project as a whole. Especially in an agency environment, where time is of the essence, this could lead to patchy work in the long run causing more problems than it actually fixes. Often it can also lead to treating the symptom, rather than the problem in fear of affecting unknown areas of the project by digging deeper.