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?"
when i was taking a class on java programming our teach had us do the following and it was really helpful: the two people would come up with a design draft and then we would take turns where one person would type code while the other partner watched and scanned the code to catch any typos or bad code. 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. this process worked very well for me. it was very helpful to have someone there to catch any mistakes or make any on the fly suggestions they have that might make the programming better or more sleek.
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 debate, I'm just offering my opinion based on years of experience.
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.
By Hg do you mean Mercurial?
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?
My Karma: ran over your Dogma
StrawberryFrog
Oh, whoops, someone just cut-and-paste details of their bank account into some code and committed without realising it.
"Administrator," you say, "can you please make that commit disappear completely out of the repository? I can't have anyone look through the history of that file and see my bank account details!"
Two scenarios: the first, the administrator uses CVS.. he types cvs admin -o 1.3 and revision 1.3 is gone! Phew! The second, the administrator uses SVN.. he says "uh, I'll get back to you on that in a few days.."
Because of this one point of difference I still don't believe SVN is a mature product.
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
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
Modest doubt is called the beacon of the wise - William Shakespeare
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 the history. They are valid views although I have formed my own over the course of time.
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.
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.
I agree with the 3 man team idea. It's the same idea as the surgical team from the Mythical Man Month. However, as is proposed here the original idea of the surgical team has changed. The best way to make a surgical team these days is to follow OOP and section of your product in manageable packages with everyone knowing what vaguely goes on in each package, but have a designated person that is known as an 'owner' or 'maintainer'. At least that's what works best for our group at work. I work on an embedded system at John Deere. We have 3 Programmers (one EE, one CE, and one CS), a Control Theory/MechE/Systems (Group Lead), and one Testing Technician (functional hardware testing). This works out really well for us. YMMV
Money is the root of all evil?