Slashdot is powered by your submissions, so send in your scoop


Forgot your password?

Technologies To Improve Group-Written Code? 74

iamdjsamba asks: "I've been working at my company as a programmer for about 4 months now, and it's apparent that the working methods could do with a refresh. Practices that we need to start changing are things like: non source-controlled changes that get uploaded to our website when they aren't ready; poor code commenting; and very little in the way of code reuse (if I write a class that could be useful to others, I have no easy way of telling everyone about it). I'm currently looking into ways to change this, and was wondering if anyone on Slashdot had experience of what's good and what's not?"
This discussion has been archived. No new comments can be posted.

Technologies To Improve Group-Written Code?

Comments Filter:
  • Wow. Quit now (Score:5, Insightful)

    by BadAnalogyGuy ( 945258 ) <> on Friday November 10, 2006 @07:21AM (#16792110)
    You clearly don't have any managers or developers with any experience because the first thing that a bright manager or an experienced developer would do is install a source control system so that you don't end up in the kind of development shithole you've found yourself in.

    I'd recommend leaving for a company that's going to be around for more than a year.
  • by CowboyBob500 ( 580695 ) on Friday November 10, 2006 @07:23AM (#16792112) Homepage
    ...for the first two (non-source controlled changes and lack of comments) is simply to tell all the developers that if they don't start doing this right now then they will be fired. Both of those things are individual problems and are some of the signs of a bad developer. If they're not prepared to improve their own personal precedures, show them the door...

  • Re: XP (Score:3, Insightful)

    by Kithraya ( 34530 ) on Friday November 10, 2006 @07:33AM (#16792136)
    Maybe Extreme Progamming can help.

    No, Extreme Programming can't help anything except to drive decent/good programmers crazy, support lazy/untalented programmers, and cut everyone's productivity in half (or worse).

    From experience with both, I highly recommend Scrum over XP any day of the week. I still hate Scrum (if I wanted to spend all of my time in meetings, I'd have become an accountant intsead of a programmer), but it's far better than XP.
  • by Bragi Ragnarson ( 949049 ) on Friday November 10, 2006 @07:34AM (#16792138) Homepage

    Create and enforce simple rules:

    1. Limit access to deployment server - only one or two person can access the server. Even better - create automatic deployment scripts that can be run on the server by those persons.
    2. Create staging server - where you deploy the code from repository. Do not deploy to production until you get a "go" from the client on staged version.
    3. Use Trac - it is a great piece of software that allows sharing information between developers. It provides wiki, ticket handling and repository viewer. And you can subscribe to wiki changes RSS so you can easily publish documentation about your classes.
    4. Use framework - frameworks usually come with a set of coding concepts that ease code reuse.
    5. Communicate findings about bad practices - just talk with your colleagues and tell them how can they write better code, with examples
    6. Introduce unit testing - person that writes unit tests gets a chance to look at own code the second time, which usually means improvements and cleanups.

    And you can always switch to Ruby on Rails. It is a good example of framework that helps doing things the right way and gets in the way when you want to do something wrong.

  • by KillerCow ( 213458 ) on Friday November 10, 2006 @07:43AM (#16792162)
    How can you do group development without source control? Do you have bug tracking? Automated builds? A deployment policy / methodology / sign-off (or just someone who is responsible for it)?

    It sounds like you've got a group of undisciplined cowboys. Good like imposing structure on them.

    Source control, and comments are absolutely required. The only reason not to do them is due to personalities, and if you have that problem, you don't have good devs.

    Where is the team lead / project manager in all this? Start there. This is a leadership problem that is causing business problems (bad releases, poor quality control, poor communication, no reuse, no reproducibility, no records).

    Look into sucking down some things from XP []. Daily stand-up meetings, unit testing, and continuous integration would be a good start. They sound bad to cowboys, but they solve these exact problems.
  • by JaredOfEuropa ( 526365 ) on Friday November 10, 2006 @07:55AM (#16792186) Journal
    It sounds to me you first need to get a few simple processes in place: building, reviewing, testing, releasing. This is no rocket science; you can probably come up with a simple, workable process yourself with a few hours effort. The real challenge is getting the rest of the team to follow your rules. You are probably not in a position to force the others to work to procedures, so talk to the other devs and the team leader, put a few ideas on paper, and convince the team leader or PM to implement those ideas together with the team.

    I would not go with anything like XP or any other far-reaching methodology. No better way to make your programmers hate you and their jobs is to force them to do things completely different. Instead, once you got the basics right, get a few guys interested in XP (or whatever), ask them to do a pilot, and get them to share their experiences. Once you've shown that it works and you have a few others championing the methodology, convincing the rest will be a lot easier.
  • by mr.hawk ( 222616 ) on Friday November 10, 2006 @07:56AM (#16792190) Homepage
    And you can always switch to Ruby on Rails. It is a good example of framework that helps doing things the right way and gets in the way when you want to do something wrong.

    In my experience people will often go out of their way to do things the wrong way. Not saying having a platform that encourages/discourages certain practices is a bad thing but without a strong leadership setting and enforcing standards I believe the impact would be minimal.
  • by Brainix ( 748988 ) <> on Friday November 10, 2006 @07:58AM (#16792196) Homepage
    I firmly believe that social problems require social solutions, business problems require business solutions, technical problems require technical solutions, etc.

    Two of the issues that you mention are poor code reuse and a lack of code comments. These sound like human problems. Don't try to solve them with technology.

    Your company may benefit from a different project management style. As many people have mentioned, you may be interested in Agile [] (specifically Scrum [] and XP []). Lightweight management, lightweight processes, and lightweight tools can breathe new life into a company.

    Good luck!
  • Re:Wow. Quit now (Score:1, Insightful)

    by Anonymous Coward on Friday November 10, 2006 @09:45AM (#16792862)

    He may not have the option to just up and leave.

    The best thing you can do is get a source control system in place now. I'm assuming you aren't very senior at 4 months, so find a senior technical person to buy into it and then take it to your manager or team lead. Once people have to "sign off" on changes it is easier to establish a build process and testing and all of the rest of what you need.

    Since we don't know how large your team is, how many projects are involved, how large the codebase is, blah blah blah I can't really suggest anything more specific, but once you have a source control system that is actually used (and is enforced and bought into) then you can start fixing the rest of the problems you have with something appropriate for your size.

    If you can't get a source control system in place then you should move on as fast as you can find a new job, as the situation will never get any better.

  • by s31523 ( 926314 ) on Friday November 10, 2006 @11:33AM (#16793996)
    Well, we can agree to disagree. I hope I didn't imply "don't comment" your code, because that is not what I propose. I propose smart, effective commenting. I like McConnell's book Code Complete, or Kernighan and Plauger's book The Elements of Programing Style. I merely agree with Kernighan/McConnell, et. al. on "Don't comment tricky code . . . Comments can't rescue difficult code" And as emphasized in The Elements of Programming Style, "Don't document bad code - rewrite it".

    And for what it is worth, McConnell references a study done by Lind and Vairavan that shows code with large numbers of comments also tended to have the most defects and tended to consume the most development effort.

    I stand by my advise to re-write code that is clunky and awkward and requires a 100 page essay to describe it.
  • Re: XP (Score:2, Insightful)

    by chromatic ( 9471 ) on Friday November 10, 2006 @12:27PM (#16794680) Homepage

    Yeah, all those terrible practices such as testing, refactoring, incremental design, customer involvement, coding standards, and ubiquitous language shared with the customer's business domain really get in the way of coding sometime.

  • by try_anything ( 880404 ) on Saturday November 11, 2006 @07:26PM (#16809060)
    Running away is the right choice. Being a "fixer" for a dysfunctional team is a job for an experienced guy with credibility and authority, who will probably be very well paid for it. A junior guy who needs to "Ask Slashdot" will not be able to make a dent in his colleagues' sloppy practices. Besides, if you're an inexperienced coder, you should be learning from people who do things right, not struggling with crappy people who set a negative example and make it hard for you to follow good practices.

Can anyone remember when the times were not hard, and money not scarce?