More People != More Progress
on March 25, 2008 @ 03:38 AM
There is a common misconception that the best way to add capacity to a project and reduce its completion date is simple—just throw more people at it. Although there is some truth in this, it is usually applied at the wrong times and it ends up having a very negative impact on the project.
This mindset that project development is a series of tasks and that somehow you can just throw people at them and everything will work out is foreign to me, because it won’t work out—at least not when it’s applied in haste.
Adding value to a project is more than completing tasks. Tasks are not isolated during project development. They are features which build on top of one another. Making good responsible decisions and understanding the code base both technically and conceptually goes a long way to help exploit easier and better ways of implementing features. This also helps keep the code base well factored, which in turn helps teams progress consistently and avoid creating a giant roadblock of technical debt which may have lurked just ahead.
basecamp goes openid
on June 26, 2007 @ 12:26 AM
Basecamp releases its support for OpenID . The official basecamp release notes can be found here .
A long time ago Brandon Keepers was telling me about OpenId but I didn’t really have a use for it (lack of support by web sites and applications that I use). One of my biggest pet peeves with Basecamp has been that you have to have multiple logins for multiple projects, but now you can have one.
My favorite feature is the new project navigation toolbar. In the below screenshot you can see the three projects that I’ve converted to OpenID show up.
Although there are a few OpenID providers out there I decided to go with My OpenID . In seven minutes I had my OpenID up and my basecamp projects converted over.
For those of you who may be interested in running your own OpenID server you can… Run your own identify server gives you some resources to show you how.
Kudos to basecamp for putting this in place, it is so far the best added feature since basecamp has been released IMO.
High Jumping Projects
on May 29, 2007 @ 12:38 AM
I spent this past memorial weekend in South Haven with much of my wife’s extended, extended family. Many of the relatives were individuals that my wife has either never met or has not seen in years. My father-in-law was eager to ask me what I’ve been up to lately for work. After about two minutes he stopped me and asked me to wait to finish because he wanted me to share the news with everyone else.
A few minutes later he was introducing me to the extended family and asking me to describe my past few months of events and work. After sharing the past few months of life and work with everyone it seems that the Q&A period started.
One of the questions sticks in my mind from one of my extended family uncles.
“When you work on your projects do you have hundreds of other developers working with you?”
I was pleasantly surprised and eager to answer his question. The answer of course is that no, I have never been on a project of more then six developers. He didn’t seem entirely satisfied so he asked another set of questions.
“When are you expected to be done with the current project you’re on? Could you be done sooner with more people?”
This leads me to the example of The High Jump principle as written in Talent Is Never Enough . The principle is such that…
Winning the high jump requires one person who can jump seven feet, not seven people who can jump one foot.
Some software projects may indeed take large amounts of people (hopefully the large amounts of people are divided into small manageable teams). So far the projects I’ve been apart of have more in common with The High Jump principle.
Brook’s Law seems to say it best:
“Adding people to a late software project makes it later.”
As John Maxwell states in his book Talent Is Never Enough , “More isn’t always better, and some things are best done by an individual.” Or in the case of most software projects, done by a small team.