Technologies To Improve Group-Written Code?

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?"

Comments

XP

[VincenzoRomano]

Maybe Extreme Programming can help a little bit.

Wow. Quit now

[BadAnalogyGuy]

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.

best practices

[StrawberryFrog]

It's a vague and non-specific question.

You've mentioned some of the practices that can help: have source control, have a build server attached to it.
Look into why this is a good idea: it automates ad-hoc, lengthy and painful build processes. Why are you getting "changes uploaded to our website when they aren't ready" ? make it so that going via the check-in and automated build is the best way to do this.

Look into code review methods.

Get some of your co-workers interested in best practices, and in being agents of change themselves. Are the problems apparent to them, or are they happy with the status quo? Can they get on your side here? Remember what the wise man (Martin Fowler) said: "if you can't change Your Organization, change Your Organization."

You don't say what tools you are working with, but in the .net world, tools like fxCop and nCover can be used, even integrated into the build process. The build can be set to break if the quality or coverage criteria aren't met. There may be such tools for your environment.

Create simple rules

[Bragi Ragnarson]

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.

Re:Create simple rules

[QuestorTapes]

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.

Re:Create simple rules

[Anonymous Coward]

7. Code reviews -- I can't tell you how many times I've caught typos or other problems in my own code as I've been explaining it to my code reviewer. I've also caught other coder's typos/problems when I've been a code reviewer. It also makes it less likely for one programmer to make a change in a dark corner somewhere and put it out there for the world to see without at least someone else's eyes having seen it first.

8. Design reviews -- if you're going to make a major change, after you've done some planning for the change but before you implement it, get other interested parties involved in reviewing your design. They may have other ideas for how to implement the change that may be better/simpler/less expensive/etc. than what you have planned, or they may have questions that will get you thinking about your own design in a new way. The design review process can be formal, in a meeting scheduled for the purpose of reviewing the design, or it can be informal, just you emailing the design to a few people and asking them what they think.

How can yo do group dev. without source control?

[KillerCow]

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.

You have a "people" problem, not a technology one.

[JaredOfEuropa]

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.

Lightweight Management

[Brainix]

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!

Real advice

[s31523]

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!

Re:Code needs comments

[s31523]

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.