In this service driven field of web design and development, having a variety of clients means having a variety of development environments. Some clients have their own development teams and need design, HTML/CSS work. Other clients have little more than a need, funds and motivation. I’ve noticed that in all these different working arrangements (either imposed or chosen or even created), one thing seems common: software created to aid developers usually makes assumptions about the scale of the development team, the processes that team requires, and the scope (in a general sense) of the project. I can’t bring any tools to mind that aid the process of varying scale.
Tools built in the way I’m imagining would have multiple “modes” which would be easy to swap to and from, allowing efficiencies for when a project is being developed by 2 people vs 20 or 200.
Part of the issue, is that all too often software is designed by programmers rather than as a collaboration with interface designers (this happens for websites too). I believe that those who primarily program are hardwired to construct interfaces for scaleability and efficiency – great attributes, but they should be strived for as a sub-goal under human friendly and appropriate-to-context.
This post feels like an unfinished thought – please feel free to conclude it in the comments, or let me know if you have recommendations for scaleable development tools.
Posted in Process |
You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.
2 Responses to “Scale of Process”
August 7th, 2007 at 2:58 pm
Great post, I totally see it now that you point it out. Dreamweaver is very scalable compared to say Coda. Both great apps but coda payed way more attention to interface design. I still have not picked witch one I like better. Coda is fun to use but Dreameaver is fast(just because I’m use to using it).
August 14th, 2007 at 2:54 am
Personally what I’ve found hardest when working on a 200 person team isn’t really the tools, there are some good ones out there, it’s getting the team to switch to them and use them. A small team is much more open to trying something new than a large one.
One combination that I find works well for all sizes of teams is Basecamp + Highrise + Subversion + Trac. It scales well and is very human-friendly. For small projects I may just put a single milestone in Basecamp, “Finish Project” while for a larger one I’ll have that broken out into many milestones, tasklists and I’ll also make it the primary place to find specs, notes, latest revs, etc. Of course this only works if everyone else uses it.
Another way I’ve scaled projects is to change the workflow. As an example I was working with a client that was using Dreamweaver’s built in publishing features and that was a *mess*. People would step all over each other and it just became unwieldly. I changed the workflow and instead of a direct FTP people had to commit their changes first to source control, which in turn would automatically push their changes to the server. This was a simple change but helped prevent stomping on each other.
I’m curious what applications got your juices flowing on this, which ones don’t think about scale or how you’re approaching a project? “Development tools” is a pretty broad subject and I’m sure my toolset is different than yours since I’m on the programmer side of the fence. For me what scales the best are using seperate tools that each do their job well, gluing it all together with workflow and supporting tools.
Really the best way to combat scalability issues is knowing a lot of little, easy to use tools vs. trying to find the one master program that can shape-shift.
Leave a Reply