Slashdot Mirror
Guide For Small Team Programming?
dm writes "I run a small design shop and have been doing more and more web development, including fairly involved back-end programming of what's now essentially become our own CMS. Up to now I've been doing all the programming myself. Now we are working with a second programmer for the first time. I already use version control (SVN) and an issue-tracking system, and I guess we are both decent at what we do — although self-taught, but we both lack experience programming in a team context. Is there a useful guide for this? Most of the tutorials I have seen for Subversion are surprisingly organized from a single coder's perspective. Where else should I look?"
Nothing beats getting together with team mates and toying with things in your spare time.
Past that, I suppose just add new people to the mix slowly.
Wanna fight ? Bend over, stick your head up your ass, and fight for air.
Both excellent books for this situation, in my opinion.
Bogtha Bogtha Bogtha
Sounds like an excellent way to keep anyone from getting into the flow.
I see your informative link, and raise you a pithy comment.
Sorry it's not about the perfect solution for your problem, but keeping
things in mind about the new context can improve things.
These are the lessons I learned from jobs and life either.
a.) be precise what you are talking about
- missunderstandings tend to poison the atmosphere at work
b.) clear missunderstandings as early as you can
c.) keep in mind that you now have a coworker
- trust him, he can do things on his own
d.) keep in touch with him
- this means you also report to him what you are doing
"primus inter pares" first within a group of similars,
you are the leader? dont behave like "the Führer"
e.) if you recognize anger, missunderstandings etc.. talk about
f.) keep in mind two programers are two human beings
g.) give him all the information you have
- if information is being held away, he would feel "pissed off".
h.)
- "smile"
- behave
- use "please" and "thankyou"
- commendation (wisely used)
g.)
let him bring some of his ideas in, discuss ideads,
if commendation comes from your boss, be modest and inform your boss if it was
your coworkers idea.
Communicate! The basic need for team work is comminication.
These are aspects I learned, when followed, it is allready team work, you don't need
a special conception for team work.
i agree w/ you about svn. we started 3 person team on svn under the assumption that it would be 'cvs but better'. after several disasterous merges we changed to hg. now we have 10 developers and everything is still working beautifully.
A couple of things -
1. I've had a lot of luck with git, as opposed to SVN. The ease with which it allows you to branch is a huge boon, and might save you some headaches as you work with other guys on your team. You might check it out.
2. I think the 37signals guys have a lot of good stuff to say on this in their book "Getting Real", which you can read for free on their web site(http://gettingreal.37signals.com/toc.php).
The original Pragmatic Programmer book is excellent I think.
http://pragprog.com/the-pragmatic-programmer
And since I also think an "agile" approach to managing software development projects is essential for most companies (certainly for any web-oriented development), I'm planning to check out their Practices of an Agile Developer book.
http://www.pragprog.com/titles/pad/practices-of-an-agile-developer
Jim
Just because you don't know how to use doesn't make it immature. I've had to do this: not quite this scenario, but somebody dumped a couple of gigs of pdfs into a common repository that gets checked out into quota'd space. The dumpfile human readable format for svn is a joy, and the tools support filtering repositories according to paths for inclusion and exclusion. Rather than just killing revisions, you can do fine-grained edits over the entire history i.e all revisions intact but one particular file erased from the history.
Out of interest, you said originally that svn wasn't as functional as cvs. What do you think is missing?
Slashdot: where don knuth is an idiot because he cant grasp the awesome power of php
svnadmin dump
(edit dump file)
svnadmin restore
A repository is a consistent history. If you want to change the history, you need reconstruct it.
I've been working with CVS and SVN for ~a decade and have never needed to delete one revision. The closest I've had to come to this is extracting a new repository from a subset of an old one. "svnadmin dump" let me do this without any trouble.
What's the stop the admin from reading the confidential info just before doing cvs admin, anyways?
æeee!
Your bank account details were commited??? WTF??? Sure they're also in some hacker hard disk since a long time ago!
Ok, somebody commited on CVS a directory with a confusing name (happens frecuently!), what's the CVS command to rename it? ...mmm... force everyone to commit, do a full copy and delete, and force everyone to checkout again? of course this is "mature" in a sense of "obsolete".
a single svn move (Rename) from the middle of a directory tree can corrupt an svndump so that svn wont import it. use svnsync now.
Often wrong but never in doubt.
I am Jack9.
Everyone knows me.
You should read the actual studies before trusting everything you see on Wikipedia. Almost all remotely scientific studies of pair programming effectiveness to date have been conducted with rather non-representative samples of the programming population, e.g., college students. They also tend to compare full time pair programming with no collaboration at all, which is unrealistic because most programmers will naturally seek a second opinion from a colleague at the times when it is most useful anyway. There is precious little research to date comparing the efficiency of two skilled and experienced programmers doing full-time pair programming with what they produce working alone except when they feel the need to collaborate in real time, and what there is isn't nearly as favourable.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Whenever I have a project at work or at home, I expect some basic things.
1. Standardized IDE. Everyone use the same thing and you will be able to do builds, deployments, and fix bugs quicker. Eclipse/Zend/VC++ whatever.
2. Communication channels. Email addresses of everyone. A group email that goes out to all teammembers is helpful. IM of everyone - Trillian, GAIM, I don't care.
3. Version control. SVN for me.
4. Project/Task/Issue/Bug tracking. I use SVN integrated with Trac at home. It's not very good compared to commercial offerings, but it works.
5. Standardized build and deployment. ANT/Bash scripts/whatever
6. Basic development practices (test/commit often), QA methodology/granularity. The more experience you have, the better you get at this.
I like to have 2-4 deployments. Production, QA - daily build via cron, Dev - build of latest commit via svn hook, and LocalDev - complete build on each developer's machine(s) pre-commit. When QA+Product Owner(s) sign off, move from QA to production as a release. This is "best case" and often you have to compromise based on necessity or need. This means up to 4 different builds and deployments, although QA and Production should be near-identical.
Often wrong but never in doubt.
I am Jack9.
Everyone knows me.
There is precious little research to date comparing the efficiency of two skilled and experienced programmers doing full-time pair programming with what they produce working alone except when they feel the need to collaborate in real time, and what there is isn't nearly as favourable.
One interesting data point is the study Evaluating Pair Programming with Respect to System Complexity and Programmer Expertise by Erik Arisholm et al. from Simula Research Laboratory, published in the February 2007 issue of Transactions on Software Engineering. There's a good summary on the Catenary blog.
This study is more realistic in that the research subjects were professional Java consultants, rather than college students. However, it appears the study did not allow the subjects to collaborate with anyone outside the pair (or at all, for the solo subjects).
The abstract of the study:
A total of 295 junior, intermediate, and senior professional Java consultants (99 individuals and 98 pairs) from 29 international consultancy companies in Norway, Sweden, and the UK were hired for one day to participate in a controlled experiment on pair programming. The subjects used professional Java tools to perform several change tasks on two alternative Java systems with different degrees of complexity. The results of this experiment do not support the hypotheses that pair programming in general reduces the time required to solve the tasks correctly or increases the proportion of correct solutions. On the other hand, there is a significant 84 percent increase in effort to perform the tasks correctly. However, on the more complex system, the pair programmers had a 48 percent increase in the proportion of correct solutions but no significant differences in the time taken to solve the tasks correctly. For the simpler system, there was a 20 percent decrease in time taken but no significant differences in correctness. However, the moderating effect of system complexity depends on the programmer expertise of the subjects. The observed benefits of pair programming in terms of correctness on the complex system apply mainly to juniors, whereas the reductions in duration to perform the tasks correctly on the simple system apply mainly to intermediates and seniors. It is possible that the benefits of pair programming will exceed the results obtained in this experiment for larger, more complex tasks and if the pair programmers have a chance to work together over a longer period of time.