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.

Re: XP

[Kithraya]

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.

Re:XP

[Gr8Apes]

Run, don't walk, away from "extreme programming". About the only thing "extreme" about "extreme programming" is the cost for maintenance after the initial release.

Re: XP

[chromatic]

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.

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.

Re:Wow. Quit now

[Anonymous Coward]

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.

Re:Wow. Quit now

[Bastard of Subhumani]

I'm assuming you aren't very senior at 4 months

He says he has four months at the company. He might have ten years experience before that. On the other hand, he might not. Because, as you rightly point out, the question has more information omitted than supplied.

iamdjsamba would do well to read this before he asks anything online again.

Easiest Solution...

[CowboyBob500]

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

Bob

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.

Re:best practices

[Ramses0]

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

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

[mr.hawk]

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.

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

[oyenstikker]

Fire bad programmers. They will undermine all your attempts if you let them.

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.

Re:Create simple rules

[Peter La Casse]

Absolutely. Mod parent up.

I was amazed to learn that reviews often have a higher rate than testing of defects found per hour. It stands to reason that when you test, you have to spend time reasoning from symptom back to cause, and when you review, you detect causes directly. There are good and bad ways to review, though, so it's worth reading about first.

Some people even call unit testing a crutch, saying that those bugs should be found in reviews, but I'm not one of them.

A technique that goes a step farther than that takes so much institutional discipline that it's rare, but that produces very high quality code: the programmer does not actually compile their code. They write it, and then send it to a QA group that compiles it and reports bugs back to the programmer. It sounds terribly inefficient, but it causes the programmer to thoroughly review the code.

Re:Create simple rules

[UncleFluffy]

A technique that goes a step farther than that takes so much institutional discipline that it's rare, but that produces very high quality code: the programmer does not actually compile their code. They write it, and then send it to a QA group that compiles it and reports bugs back to the programmer. It sounds terribly inefficient, but it causes the programmer to thoroughly review the code.

Reminds me of building large systems on a 286 box (or even older stuff - I've worked on systems on a Vax that took 8 hours just to *link*). Compile times were much longer than now, so you always checked your code over thoroughly before hitting "go".

Re:Create simple rules

[Curmudgeonlyoldbloke]

Dead right - but the rules that code reviews enforce need to be there for a reason, not just arguments about style. I once had the misfortune to be in a code review meeting where the main topic of discussion seemed to be 8-character tabs vs 4-character ones.

Re:Create simple rules

[JonSimons]

That is really unfortunate. My text editor allows me to customize the tabstop length with a single command, and could have rendered that discussion moot.

Try Agile (or Agile with XP)

[thrill12]

Seems that could be an interesting solution to your problem. More info here:

http://www.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 :)

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!

Re:Lightweight Management

[ComputerSlicer23]

Ironically, I've found a lack of comments to be fairly easy to resolve with a technical solution. Checkstyle is very handy for reminding people they forgot comments. Periodically, you still have to remind people that writing nonsensical text to get it past the automated tools is a really good way irritate the crap out of your co-workers.

Generally I've found most everyone has started to comment reasonable well once Javadocs starting getting generated regularly and people found them useful.

Kirby

Relax

[Dr. Hok]

Your problem is that you've been there only 4 months. Wait another 4 months and you're as much sedated as the others and you won't notice it anymore. Works perfectly...

Good book

[Scarblac]

Buy a copy of The Pragmatic Programmer 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.

Re:Very, very off topic

[fishdan]

You need to move to the new discussion system.

communication

[szembek]

"I have no easy way of telling everyone about it" You can send one email, and cc everyone you want to see it! Doesn't get much easier than that. Make a common classes namespace or folder or something and put very reusable stuff in there.

Re:Very, very off topic

[Anonymous Coward]

You mean like this one?
Your wish is my command!

Re:Very, very off topic

[Anonymous Coward]

And it is done. Learn to have some patience.

Source control and a big stick

[yoprst]

Source control is a must. And a hitting lazy employers with a big stick also helps.

Re:Source control and a big stick

[HighBit]

employers or employees? how do you hit your employer?

Re:Source control and a big stick

[yoprst]

Uhm, sorry. Employees indeed.

Re:Very, very off topic

[Anonymous Coward]

Here.

Static typing

[Anonymous Coward]

You don't say what language you're using, but if it's dynamically typed, you might like to look into switching to a statically typed equivalent. Static typing enforces a certain minimum level of self-documentation, reducing the damage caused by undisciplined programmers skimping on comments; it provides a certain minimum level of correctness guarantees, reducing the damage caused by undisciplined programmers neglecting to write unit tests for "obvious" cases that "can't" go wrong; and it provides guaranteed interfaces, making code reuse considerably easier and making it simpler to predict how modules of a complex system will interact.

Of course, whether this is a viable option very much depends on what you're doing, how much of an investment you have in your existing unsafe technology, what libraries you need, etc.

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!

Replies...

[iamdjsamba]

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.

Re:Replies...

[howlinmonkey]

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?

I am starting a new development group at my company, and had a similar question. Most of my work is done in C#, and I use NDoc to build class documentation. I can generate html docs, post them to an intranet site we use, and other developers can search the documentation for reusable code that does what they need. I know that similar tools exist for other languages, so take advantage of them. If you can't get your developers to consult internal resources before reinventing the wheel, you have a larger problem.

Good Luck,
hm

Re:Replies...

[Anonymous Coward]

Ah that makes it a little clearer. Javadoc can be your friend, getting people to use it may be a pita but it will take care of the problem of getting people aware of reusable code and continue to make that information instantly available to people new to the project. If you can find an intern (or do it yourself) who can be tasked with 80 hours of work or so you could probably get a good portion of the surface stuff into cvs and commented in javadoc format.

In the course of getting that code commented correctly I'd suggest using sourcenavigator.

Re:How can yo do group dev. without source control

[Gr8Apes]

It sounds like they have source control, they just don't have proper processes to only take prod code from source control.

They need leadership, without leadership buy-in, there's no way that's going to change. Until the cost of going down exceeds the costs of changing their ways, don't expect any changes.

As for XP - bah! It has some sound ideas (test test test) but that's about it. XP is a guaranteed nightmare down the road for maintenance (good for POCs though0. The meetings are actually a detriment in about 95% of the cases (I'll grant they're good sometimes) since most devolve into merely "I worked on X, Y, Z, and am behind on J" type things that just waste everyone's time. Team leads should know if someone's behind, with a 1-2 min discussion touching base with devs, otherwise, leave them to work instead of interrupting their day with a pointless "15 min" meeting. I've never seen these things be 15 minutes precisely because of the everyone feels obligated to mutter on longer than the previous person so they seem to be doing something important syndrome. If you require meetings, the team lead should summarize, and then call on anyone needing to supply deeper info, otherwise a small open session for questions, and off to work you go.

Don't they have source control?

[eggsurplus]

I'm assuming that they have some sort of source control already but just make changes and upload them to their website without checking into source control first and making sure it's tested and ready.

"non source-controlled changes that get uploaded to our website when they aren't ready"

If that's the case then it's a matter of getting new procedures put in place. Good luck with that!

A word from the inside

[spikemanuk]

Speaking as someone who works in the same department as iamdjsamba, I can offer some insights. He asked me to review this thread and provide some background information.

1. It's a 30-year old publishing company, out of which the current 20-strong IT department has evolved. The IT department was born around 15 years ago when someone had the idea of "putting some of our stuff on that new Internet thing".

2. Historically everyone has worked on small 1-person projects, hence teamwork and sharing and re-use are foreign ideas.

3. The hierarchy is very flat reflecting the above: there are a dozen or so techie software engineers, for many of them it's their first job since college and they've been here several years. There are a few managers who are somewhat divorced from what's going on in terms of software development.

I am that more experienced developer that many of you are blaming in your posts. I joined a couple of years ago. In a rare moment of strategic thinking the managers acknowledged that they have a lot to learn and formed a Process Improvement Team and invited me to join it. Unsurprisingly the first two things we proposed were a source control system and automated build tools, and we recommended that all projects should be re-organised, imported into CVS and built and deployed using ANT.

The good news is that all new projects are put into CVS as a matter of course. The bad news is that the majority of existing projects are still floundering outside of source control. there is a perception that the department is too busy to take time out to learn about new stuff (and yes I can anticipate the obvious answer to that: we'll all be less busy if we're more organised), or there is a general inertia from engineers and their managers to make sure it happens.

I've made sure that the stuff I work on most of the time is under CVS/ANT control, but on the few occasions I'm required to maintain legacy code, my blood pressure rises appreciably. I've also created a Java utilities library, and I used to send emails about new classes there, but I don't think anyone else has voluntarily used it or added to it.

We also have an in-house content management system which doesn't lend itself to source control.

I don't actually have any more to add, as I'm fast becoming one of the people who are beyond caring, and actually I've got a really important deadline to meet so I haven't got time ... ;o)

Re:A word from the inside

[Anonymous Coward]

We also have an in-house content management system which doesn't lend itself to source control.

Can the content that needs to be managed through that existing system be abstracted out enough that the actual code is in cvs? Also, javadoc can be a huge help in making people aware of classes/tools and getting them to comment appropriately - even people who hate commenting can usually be brought around once they see how useful simple documentation can be.

Re:A word from the inside

[Anonymous Coward]

Is it possible to at least snapshot the legacy stuff into CVS? I have found that even snapshotting the rolled out tree can help in emergencies.
Also, for the projects you do have in CVS, I found CVS SPAM is a life saver, it was probably the most important coordinating tool we had on a project with 10 or so geographically (and "working hours"-ly) dispersed developers. I did a separate distribution list for each project. It seemed to help team morale during tough times eg, when people would add humorous check in notes at 3 AM, etc.
The problem is if management gets wind of it and wants to be on the notification list and then does stupid shit like trying to infer productivity based on checkins - but they can do that with any CVS stats tool. Used fisheye while it was in beta, but it is $ - I was surprised though, for a Java program it worked well with mercifully near zero conf...

BTW, Damage Control was on its way to becoming a gorgeous thing - A Ruby on Rails of the continuous build/integration world - I wish google would pay them to re-activate the dev on it.
Of course, for you ANT/Maven (the Horror, the Horror) types, there is CruiseControl and others... CB/I Matrix

Wow. Run away now

[Anonymous Coward]

"I'd recommend leaving for a company that's going to be around for more than a year."

Yes, I recommend running away from any problems that life may throw your way. Can't handle job issues? Run away! Can't handle political issues? Run away! Can't deal with the opposite sex? Run away! You'll go far.

Re:Wow. Run away now

[try_anything]

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.

Fixing a devel team

[Eivind Eklund]

PRIMARY: Make development technique a priority in your group. Add a biweekly meeting where you discuss how your present processes are working and find out one thing to change per meeting. And DO hold the meeting, religiously.

I have two important specific methodologies that I've had good experience with:

Get everybody in your group on a single IRC channel and make them talk about code there, instead of face to face. This change the dynamic and tend to make things more transparent.

Make everybody review the diffs that people come up with. A good way to get this to be done reasonably easily is to make your version control mail out diffs, and then delegate review to each person in turn - say, one week each.

Eivind.

Code needs comments

[smartin]

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.

You are soooo wrong. I deal with code every day that is well written but uncommented and therefore unmaintainable and in my mind it should be thrown way. To say that code that is well written, does not need comments, is basically saying that you should be able to understand evething from the variable and function names. This may work if the code is so simple and self contained such that every thing is obvious from looking at a single source file. In the real world, especially the Object orientented world, this is simply not the case.

The fruits of the labour of professional programmers is the code they write, it should be clean, tidy and commented, otherwise it is indistinguishable from the hacks of amatures.

Re:Code needs comments

[Ihlosi]

You are soooo wrong. I deal with code every day that is well written but uncommented and therefore unmaintainable and in my mind it should be thrown way.

Well ... an issue here is what exactly should go into the comments.

Well written code should not need comments about what it is doing, unless there's absolutely no way of doing something in a non-obvious manner.

However, any code needs comments about what it should do (debugging is a lot easier if you have defined that function X should do Y, but it is really doing Z), and maybe comments about why certain decisions were made. I'm dealing with a lot of ancient code, and I always have to make up some answer for questions like "Why did they use this type of filter, and not another (more logical one) ? Was there a reason ? Did they roll dice ?".

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.

Re:Code needs comments

[Anonymous Coward]

Well ... an issue here is what exactly should go into the comments.

This is exactly why I love automated documentation tools for code. Something like doxygen gives obvious pointers about what should be documented (commented), this also can help with the problem of code reuse and bringing new developers up to speed on a project.

You'd really be surprised how quickly most developers will buy into at least making "this class does X" or "this helper function does Y" comments for the documentation system and as far as I'm concerned that is 99% of what comments should be used for in any case (the remainder being for "tricky" data structures/algorithms and tool/environment workarounds - both of which should be fairly rare). Even if many view it as a worthless pita, you can at least catch the guys who comment everything with "XXX required by stupid system" people and take appropriate action.

Re:Code needs comments

[Bill Dog]

I see the level of commenting advocated by people as a bell curve plotted over their time and experience with programming, and with a particular language:

• The noob to programming cannot yet completely appreciate the need for comments, so uses little to none of them.
• The experienced programmer but new to a particular language understands the need for comments, but the language and its common usages has not become second nature yet, so things all over the place appear to not be completely clear and thus require commenting, so comments are used liberally.
• But the experienced programmer who is also quite experienced in a given language, knows of and uses in the code the patterns and idioms of that language and its community. And therefore comments little to none, like the amateur hacker.

Which is how you might be I think confusing the two.

Re:Code needs comments

[Ihlosi]

I see the level of commenting advocated by people as a bell curve plotted over their time and experience with programming, and with a particular language:

Uh. Comments should have very little (ideally: zero) to do with the programming language used. Ideally, the comments should allow to re-create the functionality in any language, without looking at the actual code.

If I don't understand a particular construct in a particular language, I can simply look it up in a textbook.

If I don't understand why the last programmer did something, or what he was trying to accomplish, I'm out of luck. Because the last guy may be dead, have moved to Mars, or simply forgotten about what he was doing fifteen years ago.

Re:Code needs comments

[Bill Dog]

Comments should have very little (ideally: zero) to do with the programming language used.

Agreed. I think it was a bad placement of a comma that gave you that impression. Distribute "experience with" across "programming" and "a particular language" to get the correct read which was "experience with programming and experience with a particular language".

Ideally, the comments should allow to re-create the functionality in any language, without looking at the actual code.

Ugh. No. For the same reason you don't copy and paste code, but rather modularize it into one place, so the two can't get out of sync, you don't try to duplicate the functionality of the code in comments. Redundant and hazardous.

If I don't understand why the last programmer did something, or what he was trying to accomplish, I'm out of luck.

That typically occurs under one of the following three conditions:
1) The last programmer was not proficient in the language and how its developer community uses it.
2) You're not proficient in the language and how its developer community uses it.
3) The last programmer had to do something unorthodox, and didn't explain it with a comment.

To try to solve 1) or 2) with comments is fruitless and beside the point. The only real solution is knowledgeable, competent programmers writing code in expected ways. An explaining in the rare cases when that's not possible.

Re:Code needs comments

[Ihlosi]

Ugh. No. For the same reason you don't copy and paste code, but rather modularize it into one place, so the two can't get out of sync, you don't try to duplicate the functionality of the code in comments. Redundant and hazardous.

That's why I wrote "functionality" instead of "function". The comment of a function should say what the function is supposed to do (unless it's so trivial that the name of the function is description enough), i.e. "// Function returns square root of input argument". That's different from commenting what every line should do ("a++; // increment a"), which is, naturally, redundant. Unless you're coding in assembly.

That typically occurs under one of the following three conditions:

No, because it has nothing to do with the language. It might even just be a matter of certain constants. "Why did he use filter coefficients c0...c15?" has nothing to do with any programming language.

1) The last programmer was not proficient in the language and how its developer community uses it.

Ah. Never seen code written for a custom ASIC by some guy 15 years ago in pure assembly (of course, the ASIC has its own dialect), who thought he was completely above any meaningful commenting ?

Re:Code needs comments

[Bill Dog]

The comment of a function should say what the function is supposed to do (unless it's so trivial that the name of the function is description enough),...

But we need to be able to read code where functions are being called, without having to look each one of them up to see what they all do. Comments are not the answer, the function name is. And if what the function performs is too "non-trivial" to fit all in its name, I would suggest that it probably needs to be broken down further. I take high cohesion seriously, and try to stick to the good rule of thumb that a function shouldn't be any longer than a screenful.

Unless you're coding in assembly.

I've never done asm in my professional life, so I'll concede every single one of these points in that domain.

"Why did he use filter coefficients c0...c15?" has nothing to do with any programming language.

I never said any of this had to do with any programming language -- I said it had to do with one's experience with a programming language -- a misinterpretation I tried to correct previously. I don't know what your example question refers to, but a comment is certainly called-for for an algorithm that not everyone will already be typically familiar with. I.e. only need to comment the unexpected.

Development with Teams

[chris.tai]

Source control is a must. If you're working with a large team, source control technologies that include PVCS, Merant VM, or Microsoft Visual Source Safe won't work. The check in / check out features in these technologies place locks on particular files. If team members ever leave work without checking code back in, this will cause major headaches. Also, developers don't have the ability to work on the same source and merge the code back in. I'm a big fan of Subversion (SVN) or CVS. Developers are free to work on any source code file they need to. When two or more developers work on the same file, they can perform a merge to resolve any conflicts. When using source control technologies, your developers must always provide comments each time they make a new commit to the source control repository. Without this, you may as well just dump the source control software. Developers not commenting? Bad bad bad, have them follow standards. Perform code reviews if necessary.

meetings

[treak007]

Sounds like you need to hold more meetings to get everyone on the same page. You should make it so that at the meeting, each person gets a few minutes to talk about what they have done in the past week or time period since the last meeting and get to talk about what they will be working on during the next week. Also, use the first meeting to lay down some guidelines and talk of implementing some source control.

Re:How can yo do group dev. without source control

[chromatic]

XP is a guaranteed nightmare down the road for maintenance....

Precisely why?

If you require meetings, the team lead should summarize, and then call on anyone needing to supply deeper info, otherwise a small open session for questions, and off to work you go.

Hm, sort of like an XP meeting then. Hm.

Similar experience

[Kell_pt]

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 repository for every project, and one repository per person, to host "private" projects. Also, TortoiseSVN for a windows shell integration with Subversion.

- Install Trac 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 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.

Joel has this one nailed

[spinkham]

Joel Spolsky is somewhat of a blow hard, but he has some excellent articles. The Joel Test: 12 Steps to Better Code 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

Very Extreme Programming...

[Anonymous Coward]

Maybe Extreme Programming can help a little bit.

Actually, I advocate "Very Extreme Programming" in cases like these.

This best practice programming technique is not generally applicable, but it is very effective if implemented correctly. It was first popularized by the well known developers, Smith and Wesson. Smith & Wesson, Glock, and other companies produce commerical tools to assist in managing interactions with extremely difficult co-workers, which may be the only fix for the solution you find yourself in.

Good luck!

--
AC

Re:How can yo do group dev. without source control

[Gr8Apes]

XP is a guaranteed nightmare down the road for maintenance....

Precisely why?

I suppose someone was going to ask that. For anything other than small projects, XP generates generally unmaintainable code unless it's coupled with strict architectural design guidelines. Something not done in those 'XP' projects I've witnessed. Indeed, the XP advocates generally reject anything having to do with formal design architectures. Ergo, true XP as defined by the advocates generates unmaintainable code as projects scale. Hell, all large projects generate unmaintainable code unless architectural guidelines and designs are adhered to.

        If you require meetings, the team lead should summarize, and then call on anyone needing to supply deeper info, otherwise a small open session for questions, and off to work you go.

Hm, sort of like an XP meeting then. Hm.

and they never happen like that in my experience. Matter of fact, my experience jibes with that of everyone I know that's tried the XP bandwagon.

Note that I don't dismiss XP as inherently bad. It does support some good points. But as a design/project/management philosophy for large projects that have extended maintenance windows with code and requirements changes, XP will lead you quickly down the never-ending chasing your tail code-breakage nightmare. At least for any project I've been associated with. XP won't make good coders out of bad coders, or allow bad or moderate coders to generate "good" projects, despite what they want you to believe.

Make it easy to do things the right way.

[Lendrick]

I've spent the last six years developing CGI code. For the first four of those years, we had no real testing system and no source control; for the most part, we basically just made changes on the server and tested them quickly, hoping they worked. We did have a testing tree on the same server, but it wasn't an exact mirror because pie-in-the-sky development was going on there as well. There were 2 to 4 developers total (including my boss), and most of our changes were in response to frantic requests from management, who needed such and such feature RIGHT NOW. Needless to say, this was a bad system, and things were often broken in production while we worked on them.

To solve these issues, we ended up devising a system wherein we kept our source code in Subversion, and each developer had their own test tree which could be accessed from the web, so that we could test our own changes to code. When we finish making changes, we have a script to commit them and another script to put them into production. We have access to the production tree, but under a different account, so that it's inconvenient to get to it. On the other hand, our commit and go-live scripts are quick and easy to use, and now it's a completely natural thing to do, and it barely takes any more time than editing things right in production (not counting, of course, the many hours of time saved by not having to deal with bug reports or code hastily). All in all, the time savings have been huge, and these small changes have drastically reduced our downtime and bugs in production.

Furthermore, there's an understanding that once in a great while someone will need direct access to the production code. The difference is that it's harder to get to than our test code, so we only tweak production code in the extremely rare cases when it's absolutely necessary and for whatever reason it can't be done in test first (I can't recall an instance where we've actually done this, but the option is there just in case). The nice thing is that we don't take the morale hit from the lack of trust because we know that if we needed to, we could change production code.

We also have a simple home-grown web-based bug tracking system that allows our users to submit bugs and feature requests, and queues them up so we know what to work on. All people need to do to enter a bug is to put in a synopsis and description, and then attach a file if applicable. All we need to do when we fix a bug is change the status to closed and write a short message. It doesn't involve a lot of tedious and unnecessary entry on the part of either the users or the developers, so people happily use the system. The developers don't have to be told to use it at all, because it provides a simple, automated way of tracking outstanding issues. The users quickly realize that the only reliable way to get their bugs fixed is to submit them through this system (rather than stopping by our office, emailing, or calling on the phone) so they use it too.

So I guess my whole point is this: You don't necessarily need a complicated methodology. All you really need to do is set up a few ground rules and then script them so they're easy to follow, and make it inconvenient to break them. Source control is also a must (we use Subversion) as it provides everyone with peace of mind, as well as distinct points in the code that we know are stable, so we can roll production back if there's ever a big disaster. You don't have to turn all your developers into code monkeys to get solid work out of them. The key is that you not overcompensate for your problems. If you take away your developers' freedom and replace it with busy-work, you'll end up being far less productive than you could be. The good news is that your problems can be solved without having to do this.

Ack! No!

[Balinares]

Watch out, regarding code comments. They are important, even given the best written code in the world.
Why?
Well, a well-written code -- which is also a mandatory thing, to me -- will make it very clear WHAT is being done.
A comment's purpose is different: comments should tell you WHY it's being done this way.

Example of a typical bad comment:

buf[BUF_SIZE-1] = 0; /* set last byte to 0 */

And a better comment:

buf[BUF_SIZE-1] = 0; /* fill_my_buffer() sometimes fails to 0-end the buffer, making it incompatible with str* functions, so we add it here.*/

Depending on how conscientious you are, you might even want to explain why it's BUF_SIZE-1 and not BUF_SIZE. Yes, of course, YOU know. Right now. The next person peeking at the code -- which might be yourself, in three years and in a hurry -- might not, though.

Otherwise -- good post. Thanks for posting. :)

Re:Ack! No!

[s31523]

I agree with your commenting example. As McConnell puts it, "The only two kinds of comments that are acceptable for completed code are intent and summary comments".

Self documenting code, albeit a bit verbose CAN alleviate the need for many comments, even in your example. One side-note, the example provided looks like the fill_my_buffer() should be fixed rather than commenting the initialization. The code be written:

#define LAST_VALID_BUFFER_INDEX (BUF_SIZE-1)
#define NULL_TERMINATOR_TO_ENSURE_STR_FUNC_COMPATIBILITY 0

buf[LAST_VALID_BUFFER_INDEX] = NULL_TERMINATOR_TO_ENSURE_STR_FUNC_COMPATIBILITY;

So here, I would argue, no comment is needed.

DUCKS IN A ROW..

[just plain geeky]

.NET is an ideal codeing, however you need to get your ducks in a row befor you start changeing thigs. you process my be great, but you need to chack your technology and also it could be a USER error, rather than a you error....of corse is ever REALLY a user error?lol.

Why is this funny?

[mangu]

I often use some, but not all, of the techniques of extreme programming. It's a stupid name, I'll grant you that, but the so-called "agile methodologies" generally work fine.

I find it much better to have frequent prototype revisions with the customers than running a big project in successive steps, only to find in the final testing stage that the basic structure one adopted from the beginning has some fundamental flaw no one had foreseen.

tried and true 'traditional' methods work best

[way2trivial]

Try a cat o'nine tails-- they built the damn pyramids with them!

Good practices

[after fallout]

We have a couple of practices that we have put into place at my job. These are examples that are specific to the tools we use (subversion, bugzilla) but there is no reason they couldn't be generalized:

1. General release bug
1.a When any new feature or bug is found it is set as a blocker on this bug if it is to be done for the next release, if it isn't going to be done for the next release, it is set to a milestone value of future.
1.b When a release is given a date/version number we create a specific release bug and move the dependancies over to it.
2. subversion directory structure:
project\
    branches\ - contains branches of the code
    tags\ - contains named releases for development, testing releases, and new versions
    trunk\ - contains the latest copy of the source code
    published\ - contains the binary copy of the last release (to staging or production)
2.a when a production release is going to occur we tag the RC as if it is going to be the release.
2.b to commit any revision in the project you must have an open bug that you say in the commit message. I wrote a pre commit hook that checks bugzilla to see if the bug is open and if it is, it puts the message onto the bug as a comment along with a list of files that have changed. If the bug is not open (new, unconfirmed, assigned, reopened) then the commit fails.

The release must sit on the staging server until all the bugs for the deployment are verified to be fixed.

Re:How can yo do group dev. without source control

[chromatic]

For anything other than small projects, XP generates generally unmaintainable code unless it's coupled with strict architectural design guidelines.

... such as refactoring? I'm curious what other XP practices these projects didn't practice.

XP won't make good coders out of bad coders, or allow bad or moderate coders to generate "good" projects, despite what they want you to believe.

I agree with the problem of bad coders, but I'm not aware of any development process that can generate good results from monkeys by anything other than occasional happy accident.