Results tagged “project”

This morning I had an epiphany about a difference in project management style between the two major development jobs I’ve held. One style was like driving an empty bus and the other was like riding in a clown car. I am going to examine both as anecdotes from my perspective and try to avoid grandiose analysis.

The Empty Bus

So, I start the job and the first thing the company does is hand me the keys to the bus. Actually, they dither on what kind of bus to give me for several months before getting me a suitable one and give me a loaner to drive in the meantime. However, once on the bus driving, I am pretty much on my own. I have a destination to reach that has been vaguely described on a scribbled piece of paper. The directions are unclear and no one in the company has been there before. They keep changing the directions. But I get to drive. That is fun.

Every now and then, I pick somebody from the company up, they make changes to the directions and then they get off again before I go very far. Every six months, everybody climbs on to the bus and sits in the very back. They do a lot of yelling while I park and then they take away my scribbled directions and give me new scribbles to follow and a new destination to reach. But I get to drive. That’s usually fun.

All in all, I am asked to develop software with very little cooperation or direction. I am left on my own to make almost all the decisions. Even though I have weekly meetings with my manager, I am not really given much feedback on whether I’m going the right way. He’s not a developer, so he doesn’t really know enough about what I do to give me useful feedback. My quarterly reviews aren’t very cooperative or helpful, they are more about the manager wishing I would drive faster and make fewer mistakes (mutually exclusive goals when you think about it).

I nearly get into a wreck a couple times, but there’s no one on the bus to help me out. Don’t get me wrong, I’m not an excellent driver. I’m still learning, but some help should help things go faster in process, you’d think. Usually, though, my directions are so unclear and difficult to follow that I am directed to get into wrecks. This is not actually all that fun as time goes on.

The Clown Car

Clown cars are funny. They drive around in circles and then the doors pop open and an absurd number of hilarious characters hop out of the little car. This job is not quite like this. It’s actually more like a really crowded minivan, like the trip I took the other day with my wife, son, dad, mom, brother, sister, and her boyfriend, all crammed into our little Pontiac Montana. But now, imagine, that all of these people have a stake in where the van goes and have a slightly role and different idea about how to go about getting there. Now, we’ve got a good analogy. Clown cars are fun, though.

The CEO’s seat is next to mine and he gets in and out of the van whenever he feels the need. He’s a busy man: lots of vans to help. Usually, he gets in right before we wreck or near the major turns to make sure we drive carefully at those point and turn the right direction. Directly behind me sits an analyst whose job it is to navigate. He tells me where to go and annotates those instructions pretty regularly. Beside him sits another analyst whose job it is to talk to the customer and figure out what they want. He then tells the first analyst and me where we need to think about going next. I get to drive, though, they keep reaching from the back for the wheel and the pedals. That’s annoying, but still fun.

Behind the analysts sit a whole team of project managers, executives, sales people and between them and between the front seats sit a bunch of other engineers. Sometimes the other engineers help drive, make suggestions, and they often critique or commend my driving. There are a lot of people in this minivan, sometimes there’s a lot of yelling about what to do next. All the activity does make for quite a bit of fun, even if it gets a bit distracting at times.

I get to drive. As I mentioned, sometimes the analysts and engineers have their hand on the wheel and help push the pedals for me. This is pretty fun too, unlike the car though, this actually gives us a lot more control. We seem to be getting places in a much more controlled way, though we do have to control our speed much more carefully. It might take us longer, but the drive is fun along the way.

Software development in this style takes away some of my freedom as a coder. That’s a bummer in some ways, not as much fun. I like control. Yet, it also lets me focus on my strengths while others worry about talking to customers, making sure we have a plan that does what the customer wants, and while the constant feedback makes it hard to see the big picture, I usually have a lot of warning before I drive off the road or get into a wreck. Overall, this is more fun.

So far, I prefer the “clown car”/stuffed minivan to the empty bus. It’s less bipolar and more slow, steady, and directed.

Cheers.

While working at my current job, we've used three different systems to manage our projects. First, we used Trac
, which I liked very much. As we transitioned from project management into user support after the first launch of the new web site and related products we tried to use RT
for project management, which I like very much as well, but turned out to be a poor choice for what we were doing. Finally, over the past few months we've implemented a new system during Drupal
, which has been moderately successful for us. I wanted to discuss the progression briefly and explain how to use Drupal for the task of software project management.

Initially we used Trac. Trac is basically a wiki + issue tracker + code browser + milestone manager. It does those four things extremely well together. You can create wiki pages for documentation very easily. You can easily link between wiki, issues, code revisions, files, etc. You can gather your issues together in dated milestones for releases. You can track all the activity of your developers from a central timeline. All of these were working well for us. The only major drawback is that my knowledge of Python (which Trac is written in) is limited and there are things we wanted to do with it that would have required more customization than Trac is really capable of without patching it. That wasn't a show stopper. I can learn Python and we could have lived without the customizations, but it was a drawback for us.

However, Trac is not a tool that works well for end-user support since it's email integration doesn't work very well and isn't quite as transparent as I'd like. Having used RT for end-user support and loving it for that purpose, we implemented that and transitioned to RT for project tracking as well. At that point, I setup a Drupal site to sit beside the RT site to hold documentation. As far as end-user support goes, RT is the bomb. The keys, as far as I'm concerned, is the ability to logically separate support issues into queues, being able to transparently integrate email, being able to link and merge various tasks together, being able to make private technical comments on a ticket separate from replies that go out to the person with the problem (that's a killer feature), and having lots of flexibility when it comes to building email templates and triggers that send email on comment... oh, and really, really, really flexible access control. I've not seen a system for incident tracking with end-users that even comes close (not that I've seen many such systems). I've also made quite a few customizations to the system to make it more useful for us.

As far as project management goes, the RT-Drupal combo was a failure. It caused a lot of headaches, there was confusion about what was happening, and we really didn't store much of any documentation in Drupal. We should have added RT as an end-user support mechanism and kept Trac in place without modification. Had we done that, I don't think we would have implemented the Drupal system we're using now, however. Basically, I/we decided that trying to use RT to track our software projects wasn't working for us.

I suppose we could have found a way, but we decided instead to give the Drupal Project and Project Issue module a try. This decision was made for several reasons. First, we'd made a strategic decision to use Drupal as the new base platform for our central web service, the Boomer Knowledge Network
. By reusing Drupal for project management, we could more effectively reuse our knowledge and even try a few things out on the support site that could be copied on the BKN. We weren't sure it would succeed and we might have switched back to Trac again if it hadn't.

However, our use of Drupal with the Project and Project Issue modules has worked out better for our purposes at this point than I think Trac would have. The Project module for Drupal provides little to no value on it's own for us except to break up our various software projects into chunks. The Project Issue tracker, on the other hand, has all the power we need. The only major drawback at this point is the inability to assign another user to an issue //drupal.org/node/4354">http://drupal.org/node/4354, perhaps, eventually they will even agree on a fix and apply a patch!
. Other than that, it can track pretty much anything we need it to in a way that fits our team's development style [# Our development style bears some vague resemblance to Agile, but much less formally structured].

The thing that's really helped though is Drupal's CCK module. This is a customization tool that allows you to add custom fields on nodes. The Project module has a system for building releases and such, but it's really strongly geared towards how Drupal's core, theme, and module code is released, which isn't precisely the way we release our work. Rather than using it, we built our own system by building a custom Release node and then associating custom fields to link that node to a project, setting a status (in progress or deployed), a planned delivery date [# usually within 2 weeks], and a list of references to issues that should be completed on release.

We then reconfigured the states that they are defined for issues so that we have a "fixed / ready to deploy" state and a "deployed / completed" state to match with our releases. Those working on a given release can change the state of all the issues to "ready to deploy" as soon as they get everything on that issue complete. Once all of them go light green, I "schedule downtime" [# I.e., I do it late at night when our members are asleep] and perform a code push and do all the configuration necessary to finish the production release [# Usually, this is a 5 minute process, but sometimes as long as 2 or 3 hours]. Then I can mark that issue as resolved.

We also have some documentation in the system, but we're not doing as well here as we probably could. I'm also starting to build some tools using more custom node types with custom CCK fields to handle idea gathering. I'd like team members to be able to visit a site and share that link in a way similar to Digg or Delicious within the office and I'm already a good ways along on that. We're building a review system so that other staff outside the team will be able to comment on screenshots and comps so we can develop a feedback system.

I've also figured out a way to get the timeline back, which was a feature I really liked in Trac. Using the Drupal news aggregator, I can pull the feeds for code commits, issue creation, releases, and even comments [# via the Drupal Comment RSS module]. Unfortunately, I haven't found a way to pull issue followups in a way similar to Comment RSS so those are missing still, but I may just build a Followups RSS module if I have to.

Anyway, I'm pleased with how the project modules are working in Drupal for us. It's a little more flexible than Trac is (IMO) and since I'm very familiar with PHP [# I'm unfortunately familiar with PHP, which is a language I just don't like for both idealistic and emotional reasons.] and with Drupal [# On the other hand, even though Drupal is written in PHP, much of its design both internally and aesthetically is quite nice.], the code customizations are a piece of cake.

Well, that was a lovely ramble. That's what I get for writing so late after working all day....

Cheers.

There's a pretty decent article over
at A List Apart on relationship management by Keith LaFerriere from a couple weeks ago (catching up on some of my reading). I enjoyed the "Hat Head" versus "Bed Head" comparison, particularly since I'd definitely qualify myself as a "Bed Head" in my attempt to live a creative lifestyle. Though, as a developer, my idea of a creative lifestyle is probably a little different from the conception of a typical designer (less coffee and black turtlenecks and more Dr. Pepper and not-shaving).

Anyway, he makes several very important points that I think everyone in development and design need to adhere to more.

• Don't take things personally. Yes, you are being creative and it is important to you, but if you're making money doing it, you need to have a professional attitude and be willing to compromise.
• Be an example, particularly if you're the team leader. It's really amazing how much the behavior of a person is determined by the people around him. If you get ticked off every time someone does something you don't like, people around you will probably start having at least a kernel of similar behavior. This goes doubly so for managers and leaders. Your behavior sets the tone the rest of the group will judge itself by. Be good.
• Watch your language. By this I'm referring to trying to be what I would call "open-minded language." If you indicate by the adjectives you use that you're not listening or don't intend to, you will convince no one of anything. Avoid strong adjectives and try to talk as if all the options are still open even if you're already on a specific path. You can make it clear that a bad idea isn't going to fly without insulting your audience.

Anyway, I just wanted to post that link and give an infinitesimal boost to what I consider to be a good overall article on getting along with coworkers and getting the job done as a team.

Cheers.

For the past few months or so I've been dinking around with CAS
and OpenID
and a few other protocols for web single sign-on
. The reason for this is primarily because at work we run a multi-platform web site. For the main content portion of our web site we've been using Magnolia
and for the community side of the site we've been using Drupal
.

It's kind of an odd setup, but it works. The structure might change in the near future, but that's a different story. We've got a few other products and services that we're also building. However, we don't really want members to login multiple times whenever accessing a different segment of the web site. This is where single sign-on comes in.

For the initial revision of the work I created a homebrew solution of single sign-on. It's immature, it doesn't really handle some of the security concerns it really ought to, and it's maintained only be me. Needless to say, this was a quick and dirty rather than ideal solution. The plan all along was to create a tool that could provide a single sign-on service in a standard way so that we didn't have to do much, if any, of the maintenance.

My research led me to conclude that CAS (Central Authentication Service), created by Yale, is really the best solution available. There are several others out there including Cosign, Crowd, OpenSSO, and others. CAS is the most widely supported of these schemes and it implements a very robust, simple, and functional protocol.

The major drawback to CAS, for me, is that it is written in Java. This isn't a terrible issue at work since we already use a J2EE server to support Magnolia. Yet, my experience with J2EE servers (even the ones that are just servlet containers) has led me to believe that they tend to be more difficult maintain than Apache with CGI or FastCGI add ons. Furthermore, I have some interest in using CAS on my own web site, but don't have the means to host a J2EE server without changing how I host my site (and I'm very happy with DreamHost
).

Therefore, I decided to see how difficult an implementation of the CAS server protocol would be in a different language. It was not difficult. The protocol requires fewer than 10 HTTP request/responses to be implemented and the processing required to build those actions is straightforward. Viola, we have CAS+.

CAS+ implements the complete CAS 2.0 protocol. As far as I can tell (without asking as I haven't contacted anyone in the CAS realm), the CAS 3.0 protocol does not exist or does not differ from the core of CAS 2.0 in that it consists only of aspect-oriented hooks to extend CAS+.

My plans branch further in that I want CAS+ to be a more general solution to this problem than CAS is. CAS is meant for use in a totally secure environment, whereas I'm willing to sacrifice a few things for additional flexibility. I've implemented CAS+ in Jifty
and am using CAS+ as a test bed for the work I'm doing with Jesse Vincent on the "virtual-models" branch of that product. Finally, I am thinking of building CAS+ into a more general authentication solution. There's no reason why it couldn't also support some of the other SSO protocols that exist and I would love for it to be an authentication source and sink for distributed authentication protocols like OpenID.

Okay, so that was kind of a meandering way to introduce CAS+. If you're at all interested, feel free to check out the Subversion repository where it's hosted. This is the only project resource I currently have for accessing anything about it. If you want help with it, you can use the Jifty developers mailing list (see Jifty.org
for information) or see me, zostay, in "#jifty" of the freenode IRC server.

Here are the important links:

• Via Subversion: //svn.jifty.org/svn/jifty.org/CASPlus/trunk
• Brows the Web: //svn.jifty.org/jifty.org/CASPlus/trunk