Guide For Small Team Programming? 220
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?"
Experiment (Score:4, Informative)
Past that, I suppose just add new people to the mix slowly.
Staggered shifts FTW! (Score:5, Funny)
I assume you're the boss, so you could work 9am-5pm and he could work 5.30pm-1.30am.
That way you can still code naked.
Re: (Score:2, Funny)
Two obvious ones (Score:5, Informative)
Both excellent books for this situation, in my opinion.
Peopleware: Excellent Recommendation! (Score:2)
Re: (Score:3, Informative)
Re: (Score:3, Informative)
For the love of god - DON'T! (Score:5, Funny)
The optimal programmer team size is 1.
Re:For the love of god - DON'T! (Score:5, Interesting)
That answer depends on the goals for the team.
Studies and statistics have shown that 3 is actually the best number of programmers on a project. I can't find the reference now, but for a 5M line group of programs where I worked previously, we captured stats on all sorts of things. 3 was definitely the best optimization for productivity, quality, and simplicity. A team produces something better than the sum of the parts.
1 works if you are an expert on everything (or think you are) or working on a fairly trivial program or have lots of time to finish. Best of all, there's nobody else to point out your mistakes.
Re:For the love of god - DON'T! (Score:4, Funny)
A team produces something better than the sum of the parts.
+1 Avoided buzzword "Synergy"
Re:For the love of god - DON'T! (Score:4, Interesting)
Re: (Score:2)
In this case, I prefer to read that information than the joke.
I know of /. official policy about jokes, but no useful informacion should be sacrificed because of that.
Re: (Score:2)
I mean, information.
Re:For the love of god - DON'T! (Score:5, Insightful)
Only if you're some freaky self-motivated person.
Otherwise you'll surf the web all day after getting up at 1pm and watching Daytime TV for a few hours.
Two people will motivate each other. Three people might even get the time to do other business essential things, like the accounts! Also nicer for pub lunches, two people is a bit one-on-one.
More than three and I think that you start getting communications issues, unless you are all working on very different projects rather than the same codebase. Once you're in the meeting room, with the projector, and the Wii, you'll end up playing Mario Kart, which kills productivity. Also there's enough people to not have the focus on your own work, so you'll surf the web unless you're self-motivated enough or have a deadline.
Talk to each other (Score:5, Insightful)
Re:Talk to each other (Score:5, Insightful)
Wow, there are probably a few posts going to be about some program that a user loves, but this one is perfect. I've worked the last 8 years in an environment with two coders and 5 managers. What worked for us is exactly what this guy suggested and we did that in spite of what the managers wanted. We developed a perl/cgi template that all the code worked under and it worked so that either of us could look at any of the code and work with it, sharing routines and snippets. Now I'm in charge of maintaining all of it, and it's more or less like I wrote it originally. No matter what programs or coding styles are sold to you, the ONLY thing that will work is what works for the two of you and that will probably not fit into some white paper. Just find what works for you by talking and analyzing what each of you are good at. When you find it, write a paper and go on the talk circuit.
Re:Talk to each other (Score:5, Interesting)
There are lots of things I could throw out, sure, but most of them came from principle numero uno - talk to each other.
I second that. And don't just "talk to each other." There's a lot of different ways you can communicate with one another. For instance:
Do you both work independently and then regularly schedule periodic code reviews 2x a week? Or do you do code reviews on a more demand-driven basis when someone feels they have a particular milestone to show the other? Or do you sit next to one another and work in a pair-programming team?
Do you put documents in a shared place that define the design of things? When you discuss designs together face-to-face, do you take notes?
One of these answers isn't inherently better than any other, but what you should probably be striving for is to take a step back and analyze the process of developing and communicating with your partner itself, and adapt that as you, your project, etc evolve as well. So always try to communicate better this month than you did last month, where defining "better" is specific to you two. Then when the third programmer comes along, you'll have a framework to work with him in as well.
One concrete suggestion though: For your design docs and instructions on how to build and test things, start a wiki. You might be in charge of 3--5 people before you know it, and the "tacit knowledge" of how to operate your system will be continually harder to pass on without something like this.
partner learning (Score:4, Interesting)
Re:partner learning (Score:4, Informative)
Sounds like an excellent way to keep anyone from getting into the flow.
Re: (Score:2, Interesting)
Re: (Score:3, Interesting)
You mean pair programming [wikipedia.org].
Re: (Score:3, Interesting)
With the exception of that last sentence, that sounds like something I would tell someone to get out of doing any actual work.
Re: (Score:3, Insightful)
With the exception of that last sentence, that sounds like something I would tell someone to get out of doing any actual work.
Pairing does sound like taking it easy at first, but I suggest reading the whole Wikipedia article [wikipedia.org] before saying that.
Re:partner learning (Score:4, Informative)
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.
Re:partner learning (Score:4, Informative)
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 [simula.no] by Erik Arisholm et al. from Simula Research Laboratory, published in the February 2007 issue of Transactions on Software Engineering [ieee.org]. There's a good summary on the Catenary blog [wordpress.com].
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.
Re: (Score:2)
[...] that sounds like something I would tell someone to get out of doing any actual work.
It's actually incredibly productive. As one pal of mine put it, "You get third-draft code in first-draft time." Pairing is really just a special case of "two heads are better than one."
Although I've done a lot of pair programming, right now I'm working solo, and I really miss having a pair. I know there are problems with my code right now, but I won't be able to spot them myself until I come back a month later with a fresh perspective. Having a pair also saves me a lot of time in avoiding ratholes and yak s [ito.com]
Re: (Score:2)
we would switch off maybe every 20 minutes or so. this way no one person gets tired and burned out from typing or error checking.
Bah. A real programmer should be able to go 12 hours easily for sufficiently large values of doritos and mountain dew.
Re: (Score:2)
It has been observed that I'm a fairly fast and competent programmer. Now I'm sure pair programming is great for, and I'm trying very hard not to sound arrogant here, not so incredibly highly skilled brethren, but for someone who already knows what he is doing it is unbelievably painful to have someone sitting there, constantly interrupting his train of thought, adding pointless detail like "Ooh, you missed a semi-colon!", and requiring constant explanation of every character typed.
It is bad because it mean
Re: (Score:2)
Have you actually done pair programming? Maybe you did it with a dolt, or maybe you did something that I wouldn't call pair programming, like "coding with a jerk" or "having a guy looking over your shoulder while you code". But my experience is pretty different.
When coding with a junior guy, I tend to talk more about what I'm doing, so they're included. And with somebody new to pair programming, I'll explain to them that they should only interrupt for things I won't catch, and that counting to 5 or 10 is a
Re: (Score:2)
I've heard of people working in that type on environment, but personally I think that would drive me crazy. I use to have people (project manager) constantly look over my shoulder and it just made me nervous and fidgety.
Pair programming is different. You should be changing who's in control every 5-15 minutes. At first it feels weird, but it pretty quickly gets where it's just two people collaborating, and doesn't feel nervewracking at all.
Communicate with your coworker. (Score:5, Informative)
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.
Hold on there kiddo... (Score:2)
g.) give him all the information you have
In general I would agree with that advice - it's no fun [and certainly not productivity enhancing] to be in an environment where people are playing games and keeping secrets from one another.
The big exception I would make, however, is if you get even a whiff of the remotest possibility that your job might be under the magnifying glass as far as elimination is concerned.
If existing employee dude is in his late 40's, pulling down $150,000 a year, and if his heal
Divide and conquer (Score:3, Insightful)
For any enhancements you wish/are asked to make, break up the work into smaller sub-tasks and document these tasks somewhere. Then just have a free-for-all on the available work. Mark tasks as "in progress" and "done".
If you want to learn from/about each other, review each other's work. If you want to live dangerously, don't.
The best part of having a team is that you'll have multiple opinions on how to do something.
The worst part of having a team is that you'll have multiple opinions on how to do something.
Git and Getting Real (Score:4, Informative)
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).
Go out and get a beer (Score:2)
Being a team begins with being on the same page, and can't be on the same page until you know each other. If you want to be a good coding team, you to get to know each other, hobbies, interests, favorite soda, etc. Geting to know HOW the other person thinks will reduce future problems that are usually the result of misunderstanding.
Be pragmatic (Score:2, Informative)
http://pragprog.com/the-pragmatic-programmer [pragprog.com]
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 [pragprog.com]
Jim
My tips (Score:5, Insightful)
Here's what I'd suggest:
I hope that helps!
Re:My tips (Score:5, Funny)
Oops. That should be "unit tests", not "nit tests". I definitely don't recommend checking your fellow programmer for louse eggs [wikipedia.org]. Unless you're both chimpanzees. Then it would be fine.
Re: (Score:2)
> Unless you're both chimpanzees. Then it would be fine.
Have you gone berzerk? Can't you see that this man is a NIT??
Re: (Score:2)
Unless you're both chimpanzees.
Some of the programmers I have worked with may as well have been. There are some really shit programmers out there who learn a bunch of buzzwords, write a shitty GUI in Visual BASIC and convince dumb-ass HR n00bs that they are actually talented.
Re: (Score:2)
I never understood these. What's wrong with typing 'make test' frequently? But yeah, "don't check in broken stuff into mainline" is good advice.
I agree th
You need someone with this experience (Score:3, Interesting)
First, a disclaimer - My consulting company specializes in consulting on this topic, so you might consider me biased. On the other hand, I started this company because I had the experience, and saw the need.
Second, so this won't seem like a commercial, let me say I'm not answering this for any consulting opportunity... I answer slashdot questions all the time without looking for monetary gain; I'm just speaking from experience here.
There are a ton of great references for working together as a team - Any or the books from the Extreme Programming Explained series, a book on Scrum, Bob Martin's book on Agile Project Management, a dramatic reading of 'The Pragmatic Programmer', the book 'Practices of an Agile Developer' (in which several of my stories are published), or the book 'The Productive Programmer', recently published by OReilly (for which I wrote the forward), etc. But reading a book and putting it into practice are very different things. I strongly believe that teams should have mentors. (Thus the name of my company, CodeSherpas - as in we are guides to the terrain, but again, not a plug, just a reference for the kind of thing you need).
You have a fantastic opportunity here - to create a team culture where there are values like continual education, the team not afraid to learn from mistakes, peer reviews and retrospectives, iterative development, proper estimation techniques, and so on. Don't squander it. Find a good book that talks about the 'way things should be' - there are probably a zillion references here on slashdot already, but once you have that, make sure you get someone who has done it before... Even if it is just for a week of consulting/training, and then an occasional 'tune up'. And don't get a talking head... you want "visiting professor", not "ivory tower". A little bit of experience brought into your team now will mean that by this time next year, a group of ~3 awesome people who really know how to work as a team could be out-performing a team of ~7 people who just 'get it' enough to 'get by'.
-db
break it down (Score:5, Interesting)
I run a small dev team for a company of 12 people. 2 of us are 'senior' dev guys, 1 is a graphics guy in marketing, and the 4th is a guy still in school. The rest are professional services or customer reps. My company does web crawling (lots of SQL, perl, automation) and then some web stuff to display the results and various reports. Pretty much I meet with the owner once a week and we make sure we are on the same page as to what the big projects we are working on (more news coverage, some cool new chart system, etc.) then we have a really quick tech huddle every morning at 9:00. Pretty much roll your chair over and we all look at the whiteboard, what did you do yesterday, what are we working on today. Are we on track to get X done for Monday? And y done for next Monday? Every piece of every project is on the board assigned to somebody. We use source control and have a ticket system, here's a good example of how we worked on a recent project together.
We needed to write a new mail system. We mail out a few thousand reports a day to clients but our old one was prone to errors and failures. I work mostly with SQL, perl, and architecture, I suck at web/interface stuff. I know enough about it to throw a table up but it is ugly. The other senior guy is great at interface stuff, slick javascripty boxes and he's OK with backend stuff but it's never optimized and will bog down. We know what each other is good at and we like it that way! So I sat down in a conference room with my senior guy and we mapped out how to do this. A queue system, this talks to this, we need a template here, this should be stored in a db, this should be in the code, etc. Broke it all down into pieces. I took on the details loading up of the queue system, the other guy took on the reading out of the queue to send the mails. With that he gave the graphics guy the task of "Write up all the CSS to make 4 templates of daily reports, make them look cool". He would then take that CSS and dump it into the mailing code he had written. I had our Jr. guy write internal reporting of the queuing system to track when mails go out and an internal dashboard of it.
Once it was decided what we were doing nobody had to waste time in meetings or anything, just needed to talk once in a while, "Hey, I'm going to put this flag in the queue tell you which template to use, how do you want to receive it on your end?" Each piece of the project is compartmentalized, I don't even need to think, "gee, I hope the graphics line up" or "Oh man, I'll need to write an internal report for this", it's all been delegated. I just do my part, everybody does there's and when it's all done we test and I just make sure the end product is solid. "Ok, reports going out now? I'll reboot the mail server, let's see if we lose any repots, the queue handles that right?" Not having to worry about all the details makes doing my part much easier. I worried about the details when we designed it, so now it's just getting it done. In the end I'm the director and it's up to me to make sure it's done but I act a lot more like a peer as I do as much work as the other guys, but I also handle all the meetings with the other groups. My team can focus on code and banging that project out while I deal with any BS that would just slow the team down. I've found this is a huge help on moral, how bad is it when the marketing guy wants his cake and eat it too and then the whole dev team just goes back to there desk and bitches about it. Instead I just go to the meeting 1 on 1 and will say, "I think you just wanted to cake here, no eating." That way he doesn't look silly and I can go back to my team and say, "Ok, we are baking a cake." and there is no confusion. I'd say half of being a good dev leader is understand wtf the people really want (not what they ask for) and then translating that to the rest of the dev guys, "Hey, let's be solution providers, not coders."
I've found using a ticket system is helpful for people outside my department for putting requests in, for
Consistency (Score:2)
The first thing to strive for, I think, is ensuring that code on which two people work still has structural consistency. Programming can be very personal, and aside from emotional aspects such as indentation and formatting, individual programmers sometimes have very individual approaches to problems. Chaos can ensue if, for example, two people on the same project have very different approaches towards exception handling.
One way to ensure consistency is to regularly review each other's code, at least initial
Visual Sourceunsafe (Score:2)
Re: (Score:2)
SourceSafe 2005 isn't SO bad... but its still bad (its just decent because its well integrated). Team Foundation Server 2008 (2005 had some rough edges) is quite good, but that can be too expensive for some...
Because of that (I actually have TFS, but that requires a box with Windows Server and crap, and I don't have the hardware), for personal projects, I've grown very, very fond of Visual SVN... it is a commercial plugin, but the server is free (its just SVN + Tomcat wrapped in a nice friendly installer, a
From 25 years of team programming... (Score:5, Interesting)
1. Keep the team small. 2-4 people is best.
2. Ignore heavyweight Methodologies and Methodists.
3. You need a specification, a small document in the language of the customer, that describes what the customer hopes to accomplish with the software you're writing. If the customer cannot understand the spec, you're doing it wrong.
4. You need some white boards.
5. You need to get good with a pretty-printer so you don't have to waste hundreds of hours arguing about coding styles.
6. If you have documents that describe the programs and they are constantly getting out of sync with the code, write clear code with decent names and throw the documents away. On 99% of the projects I've seen (mostly Fortune 500 co's), the documentation outside the code quickly becomes actually misleading and slows people down if they read it first in their attempt to understand the code.
7. 1 talented, motivated, socially adept programmer is worth 1,000 mid-range unmotivated socially inept programmers.
Peopleware is pretty good. Mythical Man Month is better.
Good luck.
Re: (Score:3, Insightful)
I hear you on #6. I do enjoy automated documentation (like class diagram generators, API documentation tools, etc), but stuff that is done manually gets...ugh...fast...
Having a Wiki for the big stuff is a good idea, but beyond that? I'm currently working on some very very small apps (a lot of them, on a 2-3 weeks cycle per app), and when the QA or the customer points out a change request, I get scared to death.
Not because of the change itself... development tools have grown over the years, and even a signif
Re: (Score:2)
I agree. Curiously, I just blogged [dynamicalsoftware.com] on this topic just last week.
What I require for my team (Score:3, Informative)
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.
Re:What I require for my team (Score:5, Insightful)
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.
That is the dumbest thing I have ever heard. Horses for courses. I was an Emacs guy until recently when I switched to Vim. We have a couple of other Vim people and an Eclipse guy here. Everyone gets by using whatever 'IDE' that they want. The IDE does nothing except provide them an editor. Forcing the same IDE on everyone is asking for reduced productivity.
Standardized build and deployment. ANT/Bash scripts/whatever
With this you don't need an IDE preference. We have Makefiles and Ruby scripts that do everything we need. SCM actions are mangled into scripts so branching, merging, etc are all handled and the right comments (according to our policy) are inserted into the repository. Releasing to production and staging servers is handled and everything works neatly.
If you get this part right you won't have the headache of forcing a GUI guy to edit code on the console and you won't have the loss of productivity when you get a console guy to try and use a graphical (read: crap) IDE.
Re: (Score:2)
An editor and an IDE are completely different animals. If your IDE does not have an integrated version (or a broken or functionally different integration) of the VCS, you lose productivity and create problems down the line. When you have disparate IDEs and you want to add to the java path for a certain project and you show how to do it in one IDE, you lose productivity if someone else isn't familiar with
Re: (Score:2)
I actually know a lot of companies (mostly C++ shops) with hundreds of devs and no standard IDEs.
They swear by it, like the grand parent. However watching them set up their environment and all goof around is quite amusing. It takes days to get the environment set up for a new employee, because with everyone doing it differently, no one knows -exactly- how to do it (it is a very, very, very large application... think Oracle all editions and all related dev tools kind of large).
Then everyone have their own ma
Re: (Score:2)
When you have disparate IDEs and you want to add to the java path for a certain project and you show how to do it in one IDE,
And when you're tied to an IDE you're tied to devs who are comfortable and you're also relying on the fact that it will continue doing what you need it to do from now and until forever.
It's not really that hard to standardise a build/dev environment. A set of required packages installed. A set of required BASH scripts installed and bashrc (or whatever) login settings installed at the system level.
If your build is managed by Makefiles then there's no need for everyone to use your choice of shitty IDE when
Re: (Score:2)
If there's evidence the IDE is "shitty", everyone should switch to a non-"shitty" one.
There is no "my IDE" nor is there a place for personal preference over productivity in a project unless you are a masochist.
Re: (Score:3, Insightful)
If there's evidence the IDE is "shitty",
What you think is shitty and what I think is shitty are two different things.
There is no "my IDE" nor is there a place for personal preference over productivity
That's a very power-freak way of doing things. If you enforce rules like that then you're asking for trouble. I've worked in a few places now and I can tell you that the places that enforce those kind of rules almost never get very far.
In fact, the second-last job I was at was haemorrhaging people for exactly that reason. They went from 40 devs to 10 in the space of 12 months and couldn't find decent replacements because word go
Re: (Score:2)
I use emacs, vim, and eclipse, even for c++. Try it out, you need to learn about it specifically because of the very good communication tools allowing remote code collaboration and integration via mylyn with bugzilla or trac or even fogbugz ...
Don't dismiss a tool without knowledge. Ide's have come a long way since vc++ 6...
--jeffk++
Re: (Score:2)
Don't dismiss a tool without knowledge. Ide's have come a long way since vc++ 6...
I've tried a stack of tools and I always come back to the simplest ones because they're the ones that piss off into the background and let you do your job.
That said, VC6 had a nice debugger in it; I guess you need a good debugger when you're working with Windows...
Re: (Score:2)
The IDE does nothing except provide them an editor.
Depends on what you're doing for a living, but this is patently untrue with Java or C#. An IDE with good code browsing tools is much better than a mere text editor. It's like the jump from using more on a bunch of text files to using a web browser on hypertext. And a good refactoring tool makes a world of difference to productivity.
Re: (Score:2)
1. Standardized IDE. Everyone use the same thing and you will be able to do builds, deployments, and fix bugs quicker.
How do you get everyone to convert to vim? ;-) About a third the projects I've worked on have used a common IDE, and that's because it was the best thing to do, and one's life would be hell if one didn't switch. It didn't matter on the other projects, and everyone just used what they used best. I think it kind of sorts itself out that way.
IM of everyone
IM is excellent. Excellent! Even intra-office!
3. Version control. SVN for me.
I used to use SVN, but for this latest one, I switched to git (though I'm the only dev on this arm of the code for this
Re: (Score:2)
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.
I'm curious, what does trac lack, and which commercial offerings do better?
Re: (Score:2)
1)Trac integrates 1 repository per trac. While I can configure SVN to use single configs for multiple repositories, this does not translate for Trac. This means I have to set up users and permissions for every person (involved) per project which is extra work or put all my projects under a single repository, which is bad. Have not tried Trac with CVS :p
2)Attributing SVN commits based on tagged commit comments. JIRA does this and it rocks.
3)No approval mechanism or role-based approval. If I can't change a de
Lurk on the Subversion Dev Mailing List (Score:2)
I've lurked on their mailing list and I have to say I'm really impressed by the maturity of the group of developers that participate. What is really amazing is watching a new developer join and then be gently introduced into the culture of the list. That culture is polite, inclusive an respectful.
Most people soon learn the culture and participate, and the few that don't soon leave on their own accord. I think everyone who stays enjoys developing in that culture.
You may also be interested in this talk by
Stop using Subversion (Score:2)
You're going to eventually anyway. It's slow, the model is seriously constraining, and it has a bunch of extra features that really aren't all that useful.
Consider using something like Mercurial [selenic.com] (my favorite) or git instead. They are much better suited for collaborative development, especially if the teams are loosely coupled.
Re: (Score:2)
Oh dear.
I don't know if you're aware of it, but you've just made an extraordinary claim.
Extraordinary claims require extraordinary evidence.
So let's hear it.
Re: (Score:3, Interesting)
I don't know if you're aware of it, but you've just made an extraordinary claim.
I've also tried to point out that it was a personal opinion. Plenty have written about the SVN vs CVS [pushok.com] debate, I'm just offering my opinion based on years of experience.
Re: (Score:3, Insightful)
I've also read that article. It's written by someone who hasn't worked with SVN yet. From that standpoint, CVS will compare favorably.
From any other standpoint, not so much. I have experience (actual, hands on experience, not "I read it on the web" experience) administrating and using both systems. SVN wins hands down. It is more robust, it's more user friendly (no more CVS login), it has functions that CVS lacks (svn move).
SVN's creators wanted to make the next, better CVS. They succeeded. If he's already
Re:Move to CVS (Score:5, Funny)
Subversion wins, fatality.
Re: (Score:3, Informative)
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.
Re: (Score:3, Interesting)
By Hg do you mean Mercurial [selenic.com]?
What is there about it that makes developers better or worse at merging?
I'm assuming that you're not agreeing that CVS would solve this particular problem, since it merges much like SVN does?
Re: (Score:2)
maybe you should have read svn book first, eh?
Re:Move to CVS (Score:5, Insightful)
For the love of Dog, please don't move from SVN to CVS.
SVN was designed as a "compelling replacement" for CVS. And it succeeds.
I've yet to see a compelling reason to move to SVN.
That doesn't mean that there's a reason to move back. If you don't see the benefits of atomic commits, keeping version history over file moves an renames, and rapid branching [blogspot.com] then by all means, stay with your CVS. Just don't drag other people back down with you.
If nothing else, CVS is pretty much a dead end. The next version of CVS is SVN. SVN has a development roadmap, CVS has migration-to-svn utilities.
Re: (Score:2)
Well, anyday now I guess I'm going to move up from RCS.
Re:Move to CVS (Score:4, Insightful)
Because of this one point of difference I still don't believe SVN is a mature product.
I don't think it's because the SVN team are incompetent or haven't finished the basic feature set yet and their product is "immature".
It's about priorities - Oddly enough, the SVN developer team and community don't seem to have prioritised the feature of a revision-tracking system totally losing track of a revision. Priorities, as in "that's very far down on most people's list of priorities".
Re: (Score:3, Interesting)
Priorities, as in "that's very far down on most people's list of priorities".
That's fine. To me the ability to back out a bad commit is one of the highest priorities. I like a clean repository. An essential feature I've had to use, on occasion, throughout my development years.
Plus I'm very fond of RCS style diff tracking. Understanding the storage back-end is most helpful.
People have different approaches to version control. Some see it as a means of easily tracking code changes. Others see it as a managed temporary storage area and are not too concerned with the cleanliness of t
Re: (Score:3, Informative)
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 eras
Re:Move to CVS (Score:5, Informative)
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?
Re: (Score:3, Informative)
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.
Re: (Score:3, Insightful)
That's the hard way dude.
svnadmin dump -r 0:500
(asumming 501 is the bad and last revision)
Re:Move to CVS (Score:4, Insightful)
There's svndumpfilter - it can completely obliterate selected files. A complete dump/load cycle requires a bit of time, though.
See: http://subversion.tigris.org/issues/show_bug.cgi?id=516 [tigris.org]
Frankly, that's a pretty stupid reason to chose CVS over SVN.
Re: (Score:2, Informative)
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".
Re: (Score:2)
Well, that certainly is an opinion you have there. The ability to absolutely remove a revision from a source control repository is not really a positive. If a revision can be conveniently deleted, that means no truths can be gleaned from a code audit.
You can accidentally paste your bank account number on a discussion forum, and there is no technology to make people unremember it. Guess you shouldn't use Slashdot anymore then, huh?
Try Mercurial (Score:2)
I don't know whether you were speaking from experience or just making a general comment, but have you tried looking into Mercurial [selenic.com] as an alternative? It's a distributed SCMS, meaning everybody commits to their own copy of the repository and then pushes those commits to a central repository (if you go with a CVS/SVN-like centralized setup). The Mercurial interface is designed to work more or less like CVS and Subversion, and it uses patchsets and repository-wide versioning like Subversion, but it has this
Re: (Score:2)
I've not had a chance using Mercurial, so I can't judge its merits.
One of the most important pros for svn is that it has very decent tools and support. Built in in most IDEs, tortoisesvn, stuff like that. I've had a look and Mercurial does have plugins for the IDEs I use.
About blame:
svn help blame
blame (praise, annotate, ann) [...]
It's just an alias. If you want, you can praise! How is that for positive! Or ann, or annotate, if you're not into the brevity thing.
Re:svn blame (Score:2)
About blame:
svn help blame
blame (praise, annotate, ann) [...]
It's just an alias. If you want, you can praise! How is that for positive! Or ann, or annotate, if you're not into the brevity thing.
I'm aware of that, which is why I tacked that part on as a parenthetical comment. It wouldn't have a significant effect on my choice of SCMS, but if I did end up using Subversion, it would probably contribute a bit of extra stress from annoyance every time I happened across text (like "svn help") showing the "blame" command. (FWIW, Mercurial has the "blame" alias as well, but at least hides it from the "hg help" command list.) It's probably just me, but I prefer my tools to be neutral, direct and to the
Re: (Score:2)
I understand what you mean. I just know that I hardly ever use this command so it gets moved all the way back to the long storage part of the brain. Then, when I need to do an annotate, it's typically because I want to know who did that awful awful thing... so blame is exactly what I want to do (this sounds way more tightly wound than my real-life version, take with salt where needed) so that's what I remember. The alias to praise is being deliberately cute though.
Also, it may be that I miss one of the mean
Move to git (Score:2, Insightful)
If that is what you are after use git.
In general changing history is bad as it messes up
everyone who is working on that history. However
if you have to it is trivial in git to create a new branch without the bad commit and go from there.
That also matches the core simplicity argument. At it's base git is very simple, and easy to use,
and you don't even need to go to an administrator
to do all of these things, just to the guy who has
access to whos repository the changes are in.
Eric
Re: (Score:2)
You have a very valid point.
This should be easier in SVN.
However, I have done it, and it doesn't take more than a couple of minutes.
It just requires some command-line fu.
Re: (Score:2)
You don't optimise for incredibly rare situations.
What proportion of your time is spent reversing in your car? Of all the miles/kilometres you travel, what percentage?
Is there value in having a reverse gear on a car? One could argue "no" as it is only infrequently used. How about fog lights? Even less frequently used (depending on where you live). Anyone carry a spare tyre in their car? I've personally never needed a spare tyre in all the years I've been driving, yet I still carry one. I've taken the wheel off once, so having the jack has proved useful.
Re: (Score:2)
A reverse gear is very often used, and thus the mechanics to use said gear is very convenient and easy.
Many people here would argue that SVN is easy to drive on a daily basis.
Changing a tyre is considered a very rare occurrence. The mechanics for changing a tyre are relatively difficult and time consuming compared to driving in reverse.
Here your argument appeared to be that an important feature of CVS is being able to change a tyre (delete a revision) with the flick of a switch.
If your roads are made of nai
Re: (Score:2)
To debunk your bad analogy
What proportion of your time is spent reversing in your car? Of all the miles/kilometres you travel, what percentage?
I reverse at least twice a day: out of the driveway and into the road on the way to work. And then after work out of the car park and onto the road. Interesting. It's only a small percentage of distance but it is still a daily thing.
How about fog lights?
Less value, and I experience 'frequent' fog (about once a fortnight during winter) and I don't have fog lights. Why lug around the extra weight when you can either stop driving during fog or drive extra carefully with the regular lights.
Anyone carry a spare tyre in their car?
You'll find
Re:Move to CVS (Score:4, Funny)
You just have do draw a line somewhere. I for one always have some garlic, a crucifix and a wooden stake in the glove compartment, even though it's quite possible I'll never need them.
You don't and I'm not gonna hold it against you. I'm not even going to say your car isn't properly equipped.
Re: (Score:2)
Yes. And that's not optimization, it's a necessary feature. Optimization would be having seven reverse gears in your car to get optimal gas mileage in reverse.
Re: (Score:2)
In what world is it more complicated? It's less functional (from both a tool maturity and as a side effect of being LESS complicated), but I still dont understand your first "claim".
Re: (Score:3, Insightful)
To borrow from a concurrent thread, your comparison*
http://www.pushok.com/soft_svn_vscvs.php [pushok.com]
As a matter of fact, you can use any db you like if you have experience with databases and SVN. This doesn't really speak to the weakness that you are trying to describe. Transparency of data storage. This is only accurate insofar as you would say that the average SVN user thinks there is no transparency in data storage of CVS.
Re:Move to CVS (Score:4, Insightful)
You are correct that a text-storage would make recovery easier, although I have doubts that it's at all possible to recover from the Berkley DB in most cases. My question is what kind of failure partially damages a repository that you want to recover whatever part of it you can? I assume a hardware failure. SVN stores text files, binary files, directories. A text recovery for these things would never really be possible anyways. The only way to recover such data would be from a backup regardless of the version control method. SVN is backed up by simply zipping the directory and putting a copy somewhere. I do this daily & weekly. This is how recovery is usually done which is indifferent to filetype. This same approach is done with CVS but causes some serious issues when trying to get everyone back on a restored copy.
Why would we want granular access to text files in storage? If 'recovery' is high enough on the list to warrant "the primary reason", your revision control needs to have access to the backend storage, the system must have a high failure rate and I would tag it unreliable. I don't know of a reason to want access to the backend storage directly. If SVN were somehow aberrant in this regard, I would admit it, but there are lots of utilities that do not have flatfile backends and it only seems to be an issue with revision control. Sourcesafe, GIT/Bazaar with its hashed key/values or god forbid its crypto hashes, means you can't access their files directly either. Is it really assumed to be a good thing?
I believe the point of version control is to track all changes, regardless of intent (bad commits count). This does not speak to anything else including recoverability method. I find it mildly disturbing that you can or would alter the history in CVS. In SVN you basically have to dump the entire repository history to make a change to the history. The number of times I've had to restore an SVN backup is 1. That was to do a test of the integrity of the zipped repository over the last 3 years, 12 repositories and near 10000 commits. SVN is stable enough for me.
In the case where you want or need the peace of mind to be able to alter the "backend storage", I hope you have a long and prosperous career with CVS. We just have different goals.
Re: (Score:3, Funny)
To: coders@example.com
Subject: Working on main.c, leave it the frig alone until further notice. EOM.
Problem solved :D
Re: (Score:2)
You are ugly and stupid,
Love from Linus
http://www.youtube.com/watch?v=4XpnKHJAok8 [youtube.com]
Re: (Score:2)
SVN is more complicated than CVS, and less functional
Can I have some of what you are smoking?
Not that Subversion is the greatest VCS ever, but CVS is, in my opinion, a HUGE pain to use. The only reason to use it is for some sort of legacy system.
Re: (Score:2)
yeah.. mods on crack.. please do use svn and cvs in real projects before modding me troll, idiots