Tech Blog :: Pseudo-Best Practices and Tool Creep


Jul 19 '10 11:09pm

Pseudo-Best Practices and Tool Creep

Someone wrote to me recently asking if I could help them set up a Drupal development environment for an outsourced dev team. I don't have time and declined the job, but continued a brief correspondence about the requested project requirements, which I thought were interesting:.

The requirements included (each a full installation of a 3rd party software package):

Whoa.

This is the list of tools that you'll find by googling "best practices development environment" or something like that. But it's massive tool creep. Several problems I see here:

  • Toolsets need to grow organically. Dumping 10 enormous tools on a brand new team (outsourced/remote/global, let alone in the same office) is like throwing a 1000 page HR Handbook on a new employee's desk.
  • Most of these can be [ironically] outsourced to 3rd party services. There are several excellent Git hosters for example; there's no need to host a repo yourself (unless you have some crazy security requirements).
  • Tons of redundancy. Both SimpleTest and Selenium can do client-side unit testing. SimpleTest also does server-side; ditch Selenium.
  • Each of these tools requires maintenance, upgrades, TLC. The team is hired to develop a product, not maintain other companies' software, why not focus on the essentials?
  • Capistrano is great. I suggested they use Webistrano, however, and write a 5-line Ruby recipe that tells Drush to run SimpleTest before deploying. No need for Hudson anymore.
  • Issue Tracking, Wiki, and Forum? I worked on a team with Jira and Basecamp and that was more than enough for critical details to get lost. "Did you see my message from last week?" - "Which tool did you put it in?" - "I think Basecamp, but the specs are in Jira, and the wireframes in DropBox, and the timesheet in Google Docs" ... recipe for confusion.
  • This is a Drupal project. I asked several of the best Drupal developers I know if they've heard of Hudson; they hadn't. (I only have because I worked near a Java team that demo'd it for me. I didn't think it would be helpful for my workflow.) Having a list of tools like this on the job description for developers is likely to be a turnoff. Again, focus on essentials.

So I wish this project all the best. But I think they'd be much better off starting with some simple, well-known tools: Drush, SimpleTest, Webistrano OR Aegir (not both), Basecamp OR Jira OR Atrium. Better to over-use one really good tool than underuse half a dozen tools, in my opinion.

Thoughts, comments, rebuttals?

I can't speak to many of the specific tools mentioned here (though I HAVE heard of Hudson... I believe is was David Strauss who made mention of it in his blog recently).

Point being, my major pick these days is people using tools they can't maintain. Why use something like basecamp that you have 0 power to extend and control? Atrium is actually drupal based, and uh... you could make it do new stuff if you needed to... like say git integration when the d.o git work is finished... just as an example. Or hey, maybe you really need that feature and end up putting some of your own people's time into making it a reality instead of using unfuddle or something similar that does the git tracking for you.

Drupal is often accused of having a "not-invented-here" attitude, and while I can't deny that, I think it's to our great credit that we do so. The point isn't that the tool already exists, the point is that the existing tools don't fit within my workflow in an acceptable fashion, and maybe just maybe if I give it some proper love, it could actually have a reusable drupal integration that will expand our reach and influence.

I recognize that the real world seldom has extra developers to just put on a community project, but using a dozen different services to accomplish your project management task is probably just as bad (or worse) of an idea.

Eclipse

It does sound overkill to start with that many tools; even on a pretty wide scale project, you would probably end up (in the worst case) using only half of these tools. I have seen that happening for optimization/performance as well; let's just throw everything we can there, it should just be fast as hell...

Use what you really need, meaning a Git repo and Open Atrium or Redmine for a start, and build incrementally your stack when you meet actual needs (that probably is right for performance as well). Make sure at every step that what you're proposing to add is actually answering a real need, and not satisfying the geek in you or trying to resolve a human problem with a technological answer.

I didn't realize people actually use Open Atrium as an alternative to Jira or Redmine. I'd love to see a write-up from someone who's actually been using this (for some time) in a Scrum environment.

I tried Atrium for project management and quickly stopped using it. I use Basecamp instead, and on a project with 2 developers, 1 designer, 3 client contacts, and an outside advisor, it's perfect. I use private to-do lists for bug tracking, if we need to point to a revision in the code we write the revision.
I've worked with the APIs underneath Atrium quite a bit (Features, Spaces, pURL), and they're great but buggy, and the last thing I want when I'm dealing with some thorny client issue is a bug in my project management software. I've seen little bugs in Basecamp but they're small and usually handled quickly. Atrium is really a round-peg-in-square-hole example from my point of view, and while it's great for some people if it's customized by a shop to do exactly what they need, I just want something simple that works.

- Ben

It also depends on what kind of people need to use it. In my experience Redmine is beyond most techies, and I started using Google Docs. A bit messy, but it works for some clients, which is important...

I'm using Atrium for tracking issues in an office, and I find most people simply directly come to me when I'm in the office, others send me emails instead. Which is unfortunate, because it would be much better to keep track of all cases.

Then I'm using Google Wave to work with a developer, it's not a bug tracker, but I'm actually happy with it. Related issues in one place, (again) a bit messy but very fast and it grows organically.

It could be nice to have Google Wave integrated Atrium, and then with git integration :)

One of the best features of Basecamp - and someone tell me if Atrium can do this too, because it would make me reconsider it - is the ability to email directly into a project, and email a comment directly into a message thread. So anytime someone sends an email outside of Basecamp, I simply forward it in. It's a good way to remind people to keep everything in one place, and if they really hate Basecamp for some reason, at least I can keep it together so I don't have to search email threads when I need something.

I commend anyone who uses Google Wave on a regular basis... I really wanted to like it, when I saw the original demo it blew my mind, but every time I try it I decide it's too complicated or not really suited to the task and leave. They need to have much simpler bot integration for instance, the whole experience is poorly done now IMHO.

Ben

It depends on your requirements, personally I’ve given many applications a go, and base camp has covered most of the needs I’ve had so far on small scale projects. However I’ve recently up scaled and tried a few of other platforms, one of the better ones I think I am going to purchase after I have the chance to play around with it for a little longer is the project management software solution from Counter soft. Very effective.

Post new comment

Don't bother putting in spam links. They'll be set to rel=nofollow and will be removed and reported as spam shortly after submitting.

The content of this field is kept private and will not be shown publicly.
CAPTCHA
Are you human?