Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 13 down vote favorite
6

The goal is to compile a list of best practices for a development team. This can be anything from management techniques to software that make the team more productive.

Please keep one suggestion per answer and give an explanation of why you think this change will make the team better.

share|improve this question

closed as not constructive by Mark Trapp May 23 '11 at 16:13

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or specific expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, see the FAQ for guidance.

9 Answers

up vote 12 down vote

Daily Stand-up

First thing in the morning, everyone states in 60-120 seconds what:

  • was accomplished yesterday
  • what (if anything is blocking)
  • what's the goal for today.

Yeah, it's Agile, but it's a great, quick communication tool.

share|improve this answer
every single day? – stijn Oct 11 '10 at 18:19
@Stijn, yes. Here some more info: stackoverflow.com/questions/3557498/… – DevSolo Oct 11 '10 at 19:58
We do this everyday, and it works really great for getting you into thinking about work (and off facebook or SO). – Adam Harte Oct 11 '10 at 20:12
1  
And please, make sure it doesn't blow up into a 1h meeting about the latest gadgets... – cringe Oct 15 '10 at 6:13
Here is a SO question that gives pointers on daily stand-ups: stackoverflow.com/questions/3557498/… – DevSolo Oct 15 '10 at 12:32
up vote 12 down vote

Continuous Integration

Building on version control, build your project as often and as automatically as possible. Then, eat your own dog food.

share|improve this answer
This may be the single most important thing a team can do. No, second most important, after version control, because you can't really do CI without a version control system. Only fractionally ahead of unit tests, but ahead, because without a CI system running them, people get lazy, and even without tests, CI makes sure the code at least builds, plus it's trivial to set up, whereas tests add some (worthwhile!) overhead to everything you do. – Tom Anderson May 23 '11 at 15:53
up vote 8 down vote

Implementing a version control system will improve communication between developers, save time, and protect shared resources under development. I almost want to call it the founding block for a team's efficiency.

share|improve this answer
I've never encountered a serious project that wasn't using version control... hell I even used it in school for throw-away projects, do you really work in such a bad place :/ ? – Matthieu M. Oct 11 '10 at 19:31
1  
There are many small companies where the concept of version control hasn't caught on yet. I was hired right out of college to work on a project for a small consulting firm. They were not software consulting so they had no idea what they were doing and neither did I since I just got out of college. So yeah no version control there. :-) – RationalGeek Oct 11 '10 at 19:40
@Matthieu, I've seen more than one company as recently as 2008 that refuse to use it. For a variety of reasons, none of which I humbly think are valid. But they weren't using it regardless. A lot of Project.0001.zip, Projects.0002.zip, etc... though. – DevSolo Oct 11 '10 at 20:01
2  
I like to think of it like this.. Using a version control system is part of wearing pants. Having a bug tracker is the other part or wearing pants. We wear pants to work. – Tim Williscroft Oct 12 '10 at 1:40
The classic example of not using version control is The Developmestuction Environment. That raises the question of how you manage dev vs live databases (and by extension other resources) too. – Tom Anderson May 23 '11 at 15:55
up vote 7 down vote

@DevSolo suggested Continuous Integration, however i have always felt it was awkward: by the time the bot signals you that something is broken, the whole team may have contamined already.

Instead I would suggest Automated Integration: instead of having developers commit into the main repository, they ask the bot to commit for them, and it commits ONLY if the unit-tests / non-regressions all pass.

Once you get that, you don't have to worry about Continuous Integration any longer: you are assured that if you ever need to clone the main repository, you'll get a 100% validated software... which means that any regression is of your own fault :)

share|improve this answer
@Mattheiu, great answer. We do have the build servers fail on failed unit tests, etc... what software do you use to implement the bots? (perhaps you could elaborate a little, as this idea intrigues me as I'm sure others.) - TIA – DevSolo Oct 11 '10 at 20:05
Y'all can do this with a DVCS.. or commit into multiple branches if that's more your cup of tea. I guess you can use good old hudson for the bots. – Tim Williscroft Oct 12 '10 at 1:39
@Tim: spot on, we're using Hudson, though any bot would do I guess. And we're also using Mercurial which is a DVCS. We have a small command-line utility which instead of pushing the code to the main repository, enqueues a job on the Hudson server with the changes to be tried. – Matthieu M. Oct 12 '10 at 18:58
If you read the XP book, this is actually what was meant by continuous integration. Rather than having everyone check in, and then have a system for testing what's checked in, there was a machine (a physical machine, on a desk) where people had to go to check in, and weren't allowed to do so until the tests passed there. These days, we'd use a DVCS and some scripting rather than having a physical machine, but the intent is the same - passing the tests on a clean machine is a gatekeeper to checking in. – Tom Anderson May 23 '11 at 15:57
@Tom Anderson: Thanks for your input :) It makes sense, and I am afraid that Continuous Integration has been assimilated as Continuous Build, unfortunately. – Matthieu M. May 23 '11 at 15:59
up vote 3 down vote

Encourage pair programming. Destroy individualism.

And

Use Planning Poker for estimations

share|improve this answer
@Greg Domjan: done – user2567 May 23 '11 at 15:37
thanks :) – Greg Domjan May 23 '11 at 15:40
up vote 2 down vote

Continuous peer reviews. One of the biggest blockers in reviewing candidates is the fact that this happens once / twice an year. Instead, I would have the team frequently update their comments on their peers at the end of each significant task - makes management / final reviews that much more easier / detailed and gets immediate feedback.

share|improve this answer
up vote 1 down vote

In addition to DevSolo's answer on Daily standup.

When you work across geographies not everyone is awake all the time to provide in person updates 'in the morning'. Having a collaboration tool where you can share updates with the team in a more permanent form is very helpful.

It can also give the scrum master some data about who is actually participating in the sharing, with verbal reports its easy to overlook lack of contribution.

Working at Novell we use Novell Vibe Cloud.

share|improve this answer
up vote 1 down vote

Better documentation of how the code is supposed to work. This tends to get forgotten, very frequently.

share|improve this answer
Some form of company-wide wiki works great for this. – Kevin May 23 '11 at 15:56
up vote 0 down vote

I'd give a list of my best practices, but I'm afraid I'd only be plagiarizing from the book put out by 37signals titled Getting Real. It's a free read by the way. IMO, implementing as many philosophies from this book as you can is a best practice.

Seeing as how I can only pick one thing, I'd have to say ban stackexchange/stackoverflow at the office. Productivity would skyrocket!

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.