Today’s post is on something a bit different but still very much relevant in the web development world: project management. Now, I’m not all that old and I haven’t been a web developer for all that long (about 6 years in total, 3 actually getting paid but I have had the opportunity of working for a medium-sized media company with a development team of about 25 developers, a small 5-6 person development company (3 developers), and as an independent contractor.

When I began my career at the medium sized company, I initially saw my project managers as a pain in the ass. All I was interested in doing was coding. I had my own ideas of how the project or feature was going to be done and I thought that I could handle deadlines and project requirements better than they could. Was it really necessary to ask me multiple times a day what I was doing and what percentage of the project was still left to be done? PM’s gave new meaning to the phrase “avoid like the plague.” In all honesty, I wondered why in the hell these people were even hired to begin with. I just could not see the role of a project manager as being all that important.

Of course, after a bit of development work and experience doing projects with and without them, I found myself having moments of… “OMFG…where is my project manager?” As developers, void of project managers, we often get carried away with the art that is code. We plan for one thing but, weeks post-deadline, end up creating something entirely different. Does it work? Usually. Is it beautiful? Maybe. Is it what was promised to the customer? Well, no.

I’m not just talking about instances where a simple login feature ballooned into a grand hierarchical authentication scheme. I’m also talking about those projects, that for some reason or another, we just despise working on and push off completion; sometimes even writing substandard code just to get it over with. And don’t forget those projects that are just so complex that we’re not even sure if we are starting at the right place, much less dedicated to a deadline of any sort.

It seems that the problem here is not one of competence—most of us could, if we really tried to, stick within initial specs and scope. To me the problem lies in the fact that without the role of the project manager on the team, we lack the time and task management designed to keep us on track. We are trained in how to solve problems of logic through good coding principals and design. We are artists. Our canvas is digital and we sometimes let our creativity and desire for compounding beauty interfere with the job we were hired to do. We are not trained in restraint; the project manager is, at least in theory.

Depending on your experience, I suppose this next statement may be gospel or blasphemy, but to me, it is gospel all the way. The successful completion of any project hinges upon a solid development methodology based in clearly defined project goals, block specifications, complete use cases, and the division and distribution of task level development. A good project manager will be able to take high level design specs and goals from a product manager or customer contact and break them out into clearly defined and manageable building blocks. Each block can then be broken down into feature/requirement sets which can finally be tasked out to the developer/s for completion. This is the job of the project manager, not the developer. Developers should only be given spec’d out tasks with detailed use cases and an explanation of exactly what should be done. It is then up to the developer to determine how the task will be done.

Now, this is not to say that developers are not to be involved in planning or design phases of projects; by nature, they have to be. However, design and planning meetings involving developers should be focused on the technical goals of the project or block, not on management and product/customer level concerns. These meetings must be narrow in focus and should have a clearly defined result. For instance, determining the database schema for the project or settling on a development framework. The layer of abstraction here is critical in keeping the project within scope and to prevent developers from expanding on or reducing the project deliverables. Once the meeting objectives have been met, project managers should then be able to chunk and task out the technical specs to the team of developers.

Now, up until a little while ago, I hated the word “task.” Every morning I would check my email and see, “You have been assigned a new task from…” after which my head would sink low and I would seriously contemplate my career path yet again. I would constantly wonder why everything had to be a task: a task to change a misspelled word, a task to add 5 pixels of spacing to the end of the page. Wouldn’t it just be easier to send me an email or IM or for goodness sake, just turn around and tell me? Surely this couldn’t be the Zen that is programming? However, recent experience has taught me that, by God, we all need tasks just like we all need competent project managers!

Task assignment, and by extension, a good task management system (note that a task/project management system is very different from a strict bug tracking system) is an absolute necessity for project management. Proper task etiquette enabled by a solid and complete project management system serves many purposes. First and foremost to developers, it serves as our grocery list. It tell us EXACTLY what we have to do, when it needs to be done by, and contains a history of the problem or feature (most PM system tasks have comments/histories and file attachment capabilities). From the management side of things, a PM system will track the number of hours developers spend on each task which can then be used for billing or other performance metrics. It also can serve as a yardstick in determining the level of project completion by showing a variety of statistics based on ticket assignment, time used, percentage of tasks complete for a given project, and developer performance.

Not to sound too preachy (or take too much of an aside), but I have come across a number of good techniques gathered from the various project managers and lead developers I have worked with in the past that I would like to share and recommend that people use.

Quote Tasks

Make use of quote tasks. It may take a little more time and to some it may seem really useless, but in the end it will serve as a good measure of your time estimation abilities and speak to the thoroughness of your work. The way it works is that for every task you are assigned, unless fixing the problem will take less than 10 min., in the comments section you should list the files and line numbers that you will need to make changes to in addition to a brief one liner explaining the expected change. You then assign the ticket back to your project manager to quickly review. If your time estimate falls within the allowable project time, then you will get the task back and no matter how many days or weeks may pass, you will know immediately what needs to be fixed and where.

Notate Completed Tasks

When tasks are complete, you should list each file and line number range that you made modifications to and provide a one or two sentence description of changes (in addition your regular brief outlining the totality of changes). This makes tracking changes easier for those who may follow you and serves as a written history in a developers words of exactly what was done for the task.

The Six-Hour Work Day

One small tip on time management and allocation I learned from my last PM was to only allot 6 hours of estimated work in a day. He said that the remaining 2 hours are spent on bathroom breaks, water cooler conversations, task switching ramp up, nerf fights, etc. At first I thought this was strange. Could bathroom breaks really take up 2 hours of my working day? But as I was tasked on this schedule, it seemed to work out pretty well. While I didn’t exactly lose 2 hours doing random things, what did happen was that I was rarely under pressure to squeeze out tasks leaving me less stressed and able to produce better quality and more thoroughly tested code and documentation. Funny thing, comparing a “6 hour” work day with the regular, “get as much work done in the 8 hours you are here” approach, I felt more productive and competent under the 6 hour routine. Give it a try, you may be surprised.

Developers as Project Managers: Warning

Developers should never be placed in the role of a project manager; creating and managing their own tasks. However, sometimes there is little choice (little company resources, sole operation, etc). If this is the case, expect that as a developer you will be spending probably 1/4-1/3 of your day planning and managing tasks; not working on them. Be sure your boss knows this if they are not willing or able to task out projects properly to begin with. This is really for your sanity and for the thoroughness that comes with being a competent developer. Now, in the rare case where you as the developer are tasked with actually taking customer specs and being told to simply get it done, placing the entire development life cycle on you or your team’s shoulders, I strongly suggest that you ask management to hire a project manager. If that is not possible then maybe you should be dusting off that resume because project specking, chunking, and higher level project management duties like those are not your job. There is a good reason developers are not PM’s and PM’s are not developers.

The Devil’s in the Details

Nag, nag, nag. If you get assigned tasks that are too general in scope and you have any questions about exactly what it is that your PM or boss is asking for, send the ticket back and ask for further explanation. It usually only takes a few times doing this for your boss to get the idea of what information you need to get your work done right. Remember, training goes both ways; you learn from your boss as much as your boss learns from you. It’s better to take the time upfront and get accurate and detailed specs than for you to guess and have to go back and rewrite something down the road.

All that being said, there are a number of development methodologies out there to help you and your team develop software in an efficient and smart manner. Now, as I’ve made crystal clear, I’m not a PM so I don’t claim to be an expert on any development methodology, but I take particular affinity to Agile development methods like Scrum. Any methodology where you as a developer are protected from business processes (changes in specs/customer expectations, etc) external to your core job function is a winner in my book. Avoid the traditional waterfall and cowboy coding approaches as they are highly inflexible and in the former case, plain stupid as a development methodology for any business.

So there! I hope I’ve been able to give a little personal experience to you developers out there (and you managers) who may be a little too code-centric. Don’t ignore the management side of your business. It can save your sanity and make you a better developer in the process!

Its important to note that this article was not written by me.

Related posts:

1. An Engineer’s guide to Bandwidth

Also, adding notes to a table is very difficult. If I add a speech-bubble type object with a note and then want to move the table to somewhere else on the page, the speech bubble (even though it is supposedly connected to the table) doesn’t move with it.

I normally use a Mac for web development (and am even now, but am running VMware with Vista for various applications), so would prefer a Mac style diagram application. I’ll be on the lookout.

No related posts.

I was a little confused by the naming conventions of Subversion (trunks, branches and tags) and came across this excellent article that explains the reason behind this folder layout. The article can be read at http://blogs.open.collab.net/svn/2007/04/subversion_repo.html

Article

I see a lot of questions asked about “What is the recommended repository layout?”, “What does trunk mean?”, or: “What is the significance of trunk?”. This post will try to answer those questions and more.

A Subversion repository implements the metaphor of a versioned filesystem. The repository is just a filesystem with folders and files. It so happens that modifications to this filesystem are versioned and there are implementation enhancements like “cheap” copies that make certain operations less expensive than they are in a traditional filesystem, but the repository itself still behaves like a filesystem: there are no special folders or names and Subversion itself has no knowledge of trunk or branches, they are just folders within the filesystem. It is up to you as the user to give those folders names and structure that are meaningful to you.

That said, there are several common layouts that have been adopted by the community as best practices and therefore one could think of these as recommendations. If your repository is accessible to the public, following these conventions might make it easier for users that have accessed other Subversion repositories to find what they are looking for.

There are two commonly used layouts:

trunk
branches
tags

This first layout is the best option for a repository that contains a single project or a set of projects that are tightly related to each other. This layout is useful because it is simple to branch or tag the entire project or a set of projects with a single command:

svn copy url://repos/trunk url://repos/tags/tagname -m "Create tagname"

This is probably the most commonly used repository layout and is used by many open source projects, like Subversion itself and Subclipse. This is the layout that most hosting sites like Tigris.org, SourceForge.net and Google Code follow as each project at these sites is given its own repository.

The next layout is the best option for a repository that contains unrelated or loosely related projects.

ProjectA
   trunk
   branches
   tags
ProjectB
   trunk
   branches
   tags

In this layout, each project receives a top-level folder and then the trunk/branches/tags folders are created beneath it. This is really the same layout as the first layout, it is just that instead of putting each project in its own repository, they are all in a single repository. The Apache Software Foundation uses this layout for their repository which contains all of their projects in one single repository.

With this layout, each project has its own branches and tags and it is easy to create them for the files in that project using one command, similar to the one previously shown:

svn copy url://repos/ProjectA/trunk url://repos/ProjectA/tags/tagname -m "Create tagname"

What you cannot easily do in this layout is create a branch or tag that contains files from both ProjectA and ProjectB. You can still do it, but it requires multiple commands and you also have to decide if you are going to make a special folder for the branches and tags that involve multiple projects. If you are going to need to do this a lot, you might want to consider the first layout.

As for the names of the folders within the repository, again: they are just a convention. They have no special meaning to Subversion.

“trunk” is supposed to signify the main development line for the project. You could call this “main” or “mainline” or “production” or whatever you like.

“branches” is obviously supposed to be a place to create branches. People use branches for a lot of purposes. You might want to separate your release or maintenance branches from your feature branches or your customer modification branches etc. In this case, you could create a layer of folders beneath branches, or just create multiple branch folders at the top-level.

“tags” are not treated as special by Subversion either. They are a convention, perhaps enforced by hook script or authz rules, that indicate you are creating a point in time snapshot. Typically the difference between tags and branches is that the former are not modified once they are created. You might call your tag folders “releases” or “snapshots” or “baselines” or whatever term you prefer.

Remember, the significance of the name is for your benefit, not for Subversion. Finally, the architecture of Subversion, with its global revision number can often make the need for tags unnecessary. I do not think there is any reason to create tags just for the sake of creating them. If you find a need to recreate the software at a specific point in time, you can always do so by using svn log to determine the relevant revision number. Tags are best when there are “external” consumers of the repository. Maybe it is a QA/Release team that needs to perform builds, maybe it is an internal development team that wants to use releases of your code in another product, or maybe it is literally external users or customers who need to grab release snapshots from your repository. In these scenarios, creating tags is both a convenient way to be sure they get the right code, as well as a good communication mechanism to indicate the presence of release snapshots.

Hopefully this post clarifies some of these issues for you and makes it easier for you to understand how Subversion works.

I would like to finish by pointing out that a Subversion repository layout can be changed. You can always reorganize and restructure your layout after the fact. At worst, it just might create some short term pain as users adjust their working copies. It is not like you need to start over though. Just change names, move folders or do whatever to get the filesystem looking the way you want it.

Related posts:

1. Mac subversion apps – Cornerstone vs Versions