Forgot your password?
typodupeerror

Technologies To Improve Group-Written Code? 74

Posted by Cliff
from the team-building-and-improvement dept.
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:
  • by thrill12 (711899) on Friday November 10, 2006 @07:39AM (#16792154) Journal
    Seems that could be an interesting solution to your problem. More info here:

    http://www.agilealliance.com/ [agilealliance.com] (see the article library and the Agile Manifesto for more info).

    It ofcourse does depend on what type of projects you are in, I would not recommend this if you make critical applications that could endanger lives - but seeing your post I think you don't have that restriction :)
  • by QuestorTapes (663783) on Friday November 10, 2006 @08:09AM (#16792220)
    Sometimes I've found management to be an obstacle in enforcing some of these types of rules. If that happens, a few ideas for coping:

    > 1. Limit access to deployment server - only one or two person can access the server.

    Sometimes managers insist on either retaining their own access to production boxes or delgating that authority to the 'village idiot'. See below.

    > Even better - create automatic deployment scripts that can be run on the server by those persons.

    If the wrong people are given access to the production boxes, try to limit everyone's access to running a limited set of scripts that log all operations performed, along with who did them, and let you easily roll back the last change. Don't let anyone access the box directly. Then put together an automated failure report that tracks what changes occurred before the box broke. This information can be useful in the uphill battles to stop the idiots from breaking the server.

    If the question "why did the server go down?" comes up every month, it's useful to have a printout ready that says that each time it happened was immediately after Jimmy moved untested code into production, along with details.

    > @. 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.

    Also, if the validation process becomes subverted by pushes to "get it out the door", set things up so it can be easily rolled back.

    > 3. Use Trac - ...

    Never used it, but it sounds like the kind of thing you definitely want.

    > 4. Use framework - frameworks usually come with a set of coding concepts that ease code reuse.

    Maybe; some are good, some are bad. I've had the misfortune of helping developers select the right framework, only to have management scrap the recommendations and buy overpriced crap that's "oooh, shiny!". If you adopt frameworks, treat them as "on probation". Review and be prepared to get rid of them if they aren't supporting you.

    > 5. Communicate findings about bad practices - just talk with your colleagues and tell
    > them how can they write better code, with examples

    Don't preach. Write it down (Wikis are good for that), and reinforce it in a non-threatening environment like peer code reviews/stand-up meetings.

    > 6. Introduce unit testing - ....

    Agreed.
  • Good book (Score:3, Informative)

    by Scarblac (122480) <slashdot@gerlich.nl> on Friday November 10, 2006 @08:30AM (#16792270) Homepage

    Buy a copy of The Pragmatic Programmer [pragmaticprogrammer.com] for everyone in your team, and make people read it. It's a treasure.

    Then you'll at least know what the goal is; how you can get people to change their ways and habits is a problem I haven't found an easy answer to yet.

  • by oyenstikker (536040) <slashdot AT sbyrne DOT org> on Friday November 10, 2006 @09:38AM (#16792798) Homepage Journal
    Fire bad programmers. They will undermine all your attempts if you let them.
  • Real advice (Score:4, Informative)

    by s31523 (926314) on Friday November 10, 2006 @10:03AM (#16793002)
    Sounds like your organization is either relatively new to the software engineering game or just plain incompetent. The fact that you at least recognize the problem is a good thing. First, find out if there are others like you that find the current practices inefficient. If there are some others, band together and come up with an attack plan focusing on small progressive steps. You can't change the big machine overnight, so you will have to be patient.

    "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;
    Build a better practice then show it to people. Hopefully you do have some sort of CM tool for your source code and you have a couple of cowboys just uploading source code. IF you don't, check out Subversion (http://subversion.tigris.org/). To deal with the cowboys, gather some stats on the problems causes by cowboy code being uploaded and then present the hard evidence (this unapproved code cost us $5000 dollars in man-hours) to a manager. The kicker is you MUST have a plan ready to present that will cure the problem. For instance, make the server only accessable by a software librarian/integrator and only he/she can put stuff up on the server which requires code be at least built and run against the current development tip.

    poor code commenting;
    I am a proponent of well written code. If code is too complicated or hard to understand such that is needs commenting, I say re-write it. Of course there are exceptions. A good ol' fashion code review process could fix this. And I am not talking about a heavy weight CMMI process here.. Simply print out the damn code and hand it to a seasoned developer who owns a red pen.

    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).
    This happens a lot, especially with teams that haven't melded together and don't communicate well. Simple weekly stand-up meetings can help (short, 10 minute meetings in a room with no chairs) just to communicate issues and announce cool things like your nifty new class. It also helps to have a group website or message board so you can say "I did xyz, and I think everyone might benefit. See my blog/post on the group site". Don't have a site or anyone with IT skills to get one up? Try Joomla, it is an easy site content management system that is great for this sort of thing (http://www.joomla.org/)

    Good luck! If you play your cards right you could be the hero, or the zero, so watch out!
  • Replies... (Score:2, Informative)

    by iamdjsamba (1024979) on Friday November 10, 2006 @10:25AM (#16793204) Homepage
    So many things to answer.

    1) Just to give context to who I am; I am a placement student in the third year of my degree (UK based), therefore holding no power.

    2)XP is for some and not others. Having researched into it a while a go, I wasn't taken by it. And to get people to change their practices is always difficult. 3) I work in the IT department for a company that offers careers advice for students; the stuff I work on is web based: Written in java and jsps.

    4) We are gradually transitioning to a CVS; all new stuff is put into one, it's the old code that isn't in the right format. The idea of this thread was to try and find intermediary measures/ additional features to aid in my job.

    5) There are quite a few simultaneous projects, say 4 or 5, and a coding team of about 20-30 people.

    6) We already have a staging server, and all changes are made on the files on there, which is why the changes sometimes get uploaded without being ready... We have coding guidelines and tools to aid development, but most don't use them.

    7) Much of the problem arises from the fact many of the changes are minor, to one or 2 lines of code. As a result they are released ad hoc, and as they are only small there is no project manager. Everyone in the team can release content, and generally they are left to their own devices for testing and suchlike.

    8) As for emailing everyone to tell them about re-usable code, what about people joining the team at a later point? And what about when someone comes to work on something that could find the code useful, but doesn't remember the email?

    Sorry if that's a lot of very non sensical information in one go, but it gets the point accross.

    Thanks to everyone so far, it's really good hearing these comments. All comments welcomed, and i'll keep you posted as the changes happen.

  • Similar experience (Score:3, Informative)

    by Kell_pt (789485) on Friday November 10, 2006 @12:36PM (#16794770) Homepage
    We've gone through a similar experience when we grew from a team of 2 to a team of 8 in 3 months. Things we learned to be helpful in the way of tools:

    - A Subversion [tigris.org] repository for every project, and one repository per person, to host "private" projects. Also, TortoiseSVN [tortoisesvn.net] for a windows shell integration with Subversion.

    - Install Trac [edgewall.org] for every subversion project. Use it for writing documentation, and for following up on issues by posting Tickets. Tickets help a lot in maintaining the focus on problems and future developments. The integration with Subversion changesets and milestones is bliss.

    - Install the appropriate modules for Trac for permission management, and allow your customers and testers to post tickets themselves. Eases up a LOT in the way of issue tracking and fixing bugs fast. It's a great way to have other people build your to-do list dynamically.

    - Use frameworks for development. If you're programming with PHP use Symfony [symfony-project.com] for real programming (and not just random code bits).

    - Have a shared folder for files.

    - Use an appropriate database backend and install common tools for database access (phpMyAdmin, pgpPgAdmin).

    - Use the right tools for the job. As an example, remmember that MySQL works well as a fast database backend. But if you stick to MySQL for real applications where integrity and object mapping is relevant, you won't be doing real DB development unless you use views, functions and stored procedures. If you don't have these features, you'll never use them. If you use them, use PostgresSQL.

    - Buy a billboard, a big one, and have a handy set of markers available. Do not underestimate the power of a billboard.

    These are just things that worked and still work for us. There are plenty more things you can do, but first step is realizing the NEED for change, and getting everyone to work towards that.
  • Re:best practices (Score:3, Informative)

    by Ramses0 (63476) on Friday November 10, 2006 @12:57PM (#16795068)
    There are two ways to motivate people- carrots and sticks. If they don't change when you beat them with a stick then you shove the carrot... wait, what am I saying. :^) ... Stick-like motivation can only go so far, and in many corporate / company cases you personally have very little stick to whack people with. The secret is to find something that "the boss / the owner" is passionate about (it might not be technology, but instead uptime / sales / reliability, etc), and then you work to provide many carrots that will lead your coworkers on the path towards meeting your needs and what will also end up making the boss happy.

    Let me give a concrete example. I worked at a startup right around the transition from PHP3-PHP4. There was no such thing as PEAR or MVC frameworks, etc. and there was a wide variety of programming skillz at the shop. We had an existing form-validation framework that was (how to say) heavyweight. All form fields stored in databases, serialize a bazillion objects an every page-submit, session-sizes of 20-30kb for 1-2kb worth of actual data, random page-flow/state bugs, db-synchronization problems, etc. Some people liked it, some people didn't, some people said: "WTF, I will just write straight PHP and do my own ad-hoc input validation, etc" (which was OK in some cases, but made maintainability much more difficult once the form started getting complicated).

    Boss recognized that some things needed improvement, but wasn't really capable of getting involved and setting specific technical priority (and that's not really his job). He was kindof a control-freak, though, and was really keen on "seeing all the error messages that a user saw", so that he could go in and try to rewrite the forms or prompts or whatever so they'd be more clear. Anyway, I wired up some stuff so that error messages could be stored in a database ("integer"=="db" or ad-hoc strings during development), errors onsubmit were dumped into a database of $user, $app, $error, $field, $val, $time, and wrote up a little viewer that would pull errors out for sorting / filtering, and a little editor that would let you edit error messages so they were more clear.

    Then I sat back. Pretty soon boss was using error-message viewer/editor, the improvments to the framework for form validation indeed ended up fixing bugs and increasing performance both in session sizes as well as development times, and other programmers ended up getting irritated by "fix this error message, change that error message, why can't I see your error messages" stuff. Once all the tools were in place and with some gentle advocation, they took to the new system and pretty much standardized on it *of their own volition*. There really is no other way to "herd cats".

    Read the books the OP recommended, and recognize that it's about 20% technology / tool changes, and 80% convincing other people to convince themselves that there is a better way. Build lots of little carrots that *do* in fact make things demonstrably better, and make sure the existing process *is indeed* more painful than the one you are suggesting / building towards. And good luck.

    --Robert
  • by spinkham (56603) on Friday November 10, 2006 @01:22PM (#16795442)
    Joel Spolsky is somewhat of a blow hard, but he has some excellent articles. The Joel Test: 12 Steps to Better Code [joelonsoftware.com] is one of them. It's the absolute bare minimum list of things you REALLY need in a development project.

    The Joel Test

    1. Do you use source control?
    2. Can you make a build in one step?
    3. Do you make daily builds?
    4. Do you have a bug database?
    5. Do you fix bugs before writing new code?
    6. Do you have an up-to-date schedule?
    7. Do you have a spec?
    8. Do programmers have quiet working conditions?
    9. Do you use the best tools money can buy?
    10. Do you have testers?
    11. Do new candidates write code during their interview?
    12. Do you do hallway usability testing?
    Read the article for details

1 + 1 = 3, for large values of 1.

Working...