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?"
XP (Score:5, Funny)
Re: (Score:1)
Very Extreme Programming... (Score:2, Funny)
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 yourse
Why is this funny? (Score:2)
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.
Wow. Quit now (Score:5, Insightful)
I'd recommend leaving for a company that's going to be around for more than a year.
Re: (Score:1, Insightful)
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 bla
Don't they have source control? (Score:1)
"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!
Re: (Score:3, Insightful)
Easiest Solution... (Score:3, Insightful)
Bob
best practices (Score:5, Interesting)
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
Re: (Score:3, Informative)
Re: XP (Score:3, Insightful)
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: (Score:2, Insightful)
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.
Create simple rules (Score:5, Insightful)
Create and enforce simple rules:
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: (Score:3, Informative)
Re:Create simple rules (Score:5, Interesting)
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: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
Re: (Score:1)
Try Agile (or Agile with XP) (Score:3, Informative)
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
How can yo do group dev. without source control? (Score:5, Insightful)
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 [extremeprogramming.org]. 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.
Re:How can yo do group dev. without source control (Score:1)
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 abo
Re: (Score:1)
Precisely why?
Hm, sort of like an XP meeting then. Hm.
Re: (Score:1)
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.
Re: (Score:1)
... such as refactoring? I'm curious what other XP practices these projects didn't practice.
I agree with the problem of bad coders, but I'm not aware of any development process that can generate good results fr
You have a "people" problem, not a technology one. (Score:5, Insightful)
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.
Re:Create simple rules (Score:2, Insightful)
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.
Lightweight Management (Score:5, Insightful)
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 [wikipedia.org] (specifically Scrum [wikipedia.org] and XP [wikipedia.org]). Lightweight management, lightweight processes, and lightweight tools can breathe new life into a company.
Good luck!
Re: (Score:2)
Generally I've found most everyone has started to comment reasonable well once Javadocs starting getting generated regularly and people found them useful.
Kirby
Re:Create simple rules (Score:4, Informative)
> 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.
Relax (Score:2, Funny)
Good book (Score:3, Informative)
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.
Re:Very, very off topic (Score:1, Offtopic)
communication (Score:2)
Source control and a big stick (Score:1)
Re: (Score:1)
Re: (Score:1)
Real advice (Score:4, Informative)
"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!
Code needs comments (Score:2)
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
Re: (Score:2)
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 real
Re:Code needs comments (Score:4, Insightful)
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: (Score:1)
Re: (Score:2)
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
Re: (Score:1)
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
Re: (Score:2)
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 differ
Re: (Score:1)
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 seri
Ack! No! (Score:2)
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:
And a better comment:
Re: (Score:2)
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_FU
Replies... (Score:2, Informative)
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; a
Re: (Score:2)
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 fo
A word from the inside (Score:1)
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 ar
Fixing a devel team (Score:2)
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 revie
Development with Teams (Score:1)
meetings (Score:1)
Similar experience (Score:3, Informative)
- 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.
Joel has this one nailed (Score:3, Informative)
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
Make it easy to do things the right way. (Score:2)
DUCKS IN A ROW.. (Score:1)
tried and true 'traditional' methods work best (Score:2)
Good practices (Score:1)
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