• Don't "share" code - reuse code. Create a set of infrastructure modules that everyone reuses.
• Document APIs - you can't reuse what you don't understand how to use
• Tests - most people rewrite the wheel because they don't trust the other code. Seeing 1000 tests pass goes a long way to giving someone confidence.
• Source Control - everyone checks their stuff in and can see the latest versions.
• Managerial dictates - sometimes you need a whip to get out of your rut.

Ultimately, you need to soft-sell them on the benefits. If you and a coworker started to reuse each other's code, you can demonstrate how you found a bug in his code that he'd been trying to fix for months (and vice versa). Two heads working together are better than three heads apart, and all that jazz.

I agree, especially concerning tests and documentation.

Documentation is good. Tests are good. If they are done right, it's even better. But hardly anyone wants to spend a lot of time writing tests or documentation, so even just some people documenting and testing bits of the same code will make it better than having everyone go out and re-invent the wheel.

Make sure you make it easy to adapt, test and document the code. That's where revision-control comes into play. I'm using CVS at the moment for most of my projects, but subversion is looking to be the best thing since CVS. I've only used it on 2 projects, yet, but as soon as I've got the time, I'm planning on switching my CVS repository to subversion.

I would also recommend using some sort of Wiki for "general" documentation (introduction to a module, giving an overview of the whole code library/project) - just because it's easy to change will mean that people will actually update the docs. Remember, programmers should be lazy :-) If it's easier to write a new plain text-file in some obscure subdirectory than to update a word-document in the project-document system, guess what they'll do. Avoid wordprocessors for documentation as much as you can. Programmers hate them: they're big, slow and you can't write code in them. A good Wiki is much easier.

updated: spelling.

"What should it profit a man, if he should win a flame war, yet lose his cool?"

I would also recommend using some sort of Wiki for "general" documentation (introduction to a module, giving an overview of the whole code library/project)

Where I work they have recently installed Trac, which is, to quote from the home page, "an enhanced wiki and issue tracking system for software development projects". Personally I find it quite handy, effective and useful both as a web-based interface to svn and as a wiki and I particularly appreciate its terse and clear, minimalistic, look & feel.

This one comes up for me every so often. I tend to find there is little one can do on the merits of the code. Mainly it involves lots of talking. Getting inside peoples head, and convincing them one by one.

But I do think that sharing promotes sharing. A local code repository of shared code might help. Perhaps all the POD transformed to HTML and searchable from a web page -- your own mini cpan/search.cpan. Definitely more docs.

Also make sure you use others code -- set a good example.

But mainly I think it takes time, and talking

we've bounced around the idea of setting up a wiki that would function as a plaec to talk about our modules and what they do - so we at least know what everyone is up to and doing.

If you can easily get together physically, discuss things that way. We have two meetings a week involving all our developers: one where we all say what we're up to (a typical weekly meeting) and one where we review a particular piece of code or a process.

We have a Wiki, and we use it to document the conclusions we reach, but I can't imagine using it to replace focused meetings with a clear agenda.

You basically have to know what they like and fear and come up with a set of goals/changes they can live with. Some folks are stubborn and won't live with anything you suggest -- I work with folks that tend to be much smarter than I am, and personally nice, but they don't change work habits easily.

Pain isn't going to work around here. There isn't any person who can tell all of the coders how it will be. Any change will have to be by consensus of all the coders, or at least a majority of them. So i guess pleasure is the key here...

The way that some people go about the task of developing software, you'd think that the primary activity was typing. This is made evident by voluminous amounts of ill-considered code that is both brittle and rife with duplication and kludgery. As the size of such a code base grows over the years it becomes increasingly unwieldy and convoluted, the result of which is a snarled mess that is damned near impossible to negotiate. Change becomes a painful and risk fraught proposition. Development slows to a crawl.

Integral to any good software development process is that of refactorization. When implementing software it is an incontrovertible fact of life that you are going to make design mistakes. You must accept this. However, if you can go beyond just accepting this and also proactively set about resolving these mistakes, then you can prevent them from compounding and piling up over time.

To this end, you cannot always be obsessed with creating new features. You must also allocate time to pondering where you are, how you got there, and what you can do to solidify and simplify your present code base. This gets back to my original point... Developing software isn't just about sitting at a keyboard and banging out code. Rather, it is an intensely political process, one that involves extensive communication and negotiation. Engaging in such coordination efforts means less time coding, but the time you do spend coding will be more productive, more than paying back your investment.

So, to this end, you must make refactorization periods a regular component of your development cycle. Of course, this also entails that you must have an excellent automated regression testing framework. You cannot have the boldness to refactor your code as needed without the knowledge that you are not breaking functionality as you do it. Creating such a framework is a lot of work, but it's something that you really ought to have anyway.

Being able to refactor effectively when you're on a team of several developers also requires having good documentation. Refactorization involves detecting duplication in code, and said duplication is difficult to find if you must manually scan your entire code base. Instead of reading code, you ought to be able to locate such duplication by performing a cursory scan of high level module documentation.

This won't be easy. In fact, it may be quite hard, as you are recognizing. Some people are stuck in their ways, and other people take no pride in their work, merely wanting to collect a paycheck and go home. As such, if you want this to happen, you may very well have to be the spearhead. Good luck. On the plus side, if your execution is good you may win serious brownie points with management for being proactive.

Thanks for this post. It reminded me of why I rewrote lots of this code on this project in the first place - tons of for loops that could have been skipped by setting some variable to the length of an array, HTML forms that required parsing the input names instead of grouping them together in an array, and so forth. Refactoring is my strong point in coding (well, at least that's what I think). This code had maybe never been refactored and was a huge mess of spaghetti.

Perhaps I should organize a meeting sometime to discuss refactoring and why it might be a good thing. Man, the more I read everyone's comments, the more I realize what a mess my group is in - no tests, no real organization, no code reviews...

rachel

We are "in the middle" of that process.

I wont go into details, since they are a matter of your team / workgroup / bunch of people and the environment, they work. So said: the details might change a lot, and what does fine for me and my co-workers, could utterly fail for you. The bright side of this: You and your co-workers have a lot of freedom to choose the details.

I'll limit my rant to two important things, we had have / have / will have to learn:

1. the process is a process.

You start it, and it'll never terminate (or you've failed). There is no end, but after reaching a certain, defined goal ("We have a meeting each morning at 09:30, which will last 15 minutes."), the process will start over on the next iteration.
Think about a loop, where you'll change a little $Something at each step.

Be prepared for a really long-ranging engagement. Be carefull -- don't throw your heart in it! You can get badly hurt. You and your brethren need to be involved in a more than one manner, even an emotional one. But think of having a emergency cutout. (1)

2. Sharing code is as much about code as computer are about telescops (2)

Clarify the expectation what to share. We are dedicated to share knowledge in a 3-fold manner: practical, theoretical and ... well, let's say: phisolophical knowledge.

The first is obvious: "use strict;", "When getting error A, turn wheel, drop switch and head at north", "Sacrify a virgin over the router" ... that kind of advice. There is one person in charge of collecting, classifing, evaluating, augmenting, publishing etc. said information. Obviously, that person has a need for some appropriate tools.

The second layer of sharing are "brown bag lessons", i.e. we got some company time and time of ourself (that ranges from 1 hour company time for 1 hour personal time to none company time at all, depending on the topic) and some company ressources (computer, rooms, light, coffee ...) for teaching and taking lessons. I "teach" -- I prefer the word "tutor" -- perl at a very low level at 3 co-workers and take a lesson in some Windows topics. A SQL-workshop is planned, but not yet scheduled.

The third layer of sharing is somewhat strange. Every now and then, during a coffee break, a smoke or whatever time is applicable, you talk with some co-worker about the meaning of things. What's the benefit of object orientation? Why should one learn yet another language? How looks a Unix / Windows / whatever system from the viewpoint of an administrator? Those talks are helpfull in learning the ways the other one (and oneself) tends to think.

Enough! I hope, there one pinch of grain in this abundance of sugar.

(1) I was there and I've got that t-shirt. So, I'm just whininge about my own shortcomings.

(2) "Computer science is as much about computers as astronomy is about telescopes." -- Edsger Dijkstra, 1930-2002

Examples off the top of my head are

• Cash for each library used within a certain time frame
• Lunch out for those who've migrated to using x modules at the end of a month
• Golf day
• etc...

-Scott

hmmm - since we are government, won't be able to do those type of rewards.
Though I do have a mean brownie recipe that many of my coworkers are fond of...

Hey, that's a pretty good idea ... you can give out "brownie points" - literally! As a "team motivator", keep an eye on the situation, and give out points, and when the team reaches 20 points, you bring in a batch of brownies...

Although, admittedly, it would be much nicer if everyone just got along and you didn't need to bribe 'em.

Personally, I am the one that gets to dictate the coding standards for perl in our team, and I've found that pointing out problems during code reviews is extremely useful in getting people to think my way. That is, pointing out what scenarios the person's code doesn't handle, why it isn't flexible, what type of future requirements to keep in mind when coding.

And then I also point out in future code review sessions where these changes have come in useful. Changing requirements sometimes end up meaning no code change because of how flexible the code is¹. And it's those lightbulb moments that really get us all on the same page. Our manager sees "changing requirements" and equates it to "delta work" (extra work we didn't sign on for). And when we actually don't do any extra work, even though our manager thinks we did, that just improves our perceived performance. And my teammates love it.

¹ I didn't take any computer science, so bear with me if my terminology is a bit off. I subscribe not only to object-oriented methodologies², but also to what I call data-oriented methodologies. What I mean is that I put the common stuff into a data store of some sort (even if that's a hard-coded hash or array), and then loop through the data to do what I need instead of unrolling the loops and duplicating code. 90% of our data for my primary project is stored external to the code, and I'm trying to find ways to get the other 10% moved out, too. I do this in perl, C, C++, Java ... and am trying to do it in shell script, too, but Bourne shell is extremely limiting for this ;-)

² I like OO, but I am not a purist. I probably use OO more than many people, but definitely not 100%. Not everything is an object. Lots of stuff is, but not everything. For example, using perl6-isms, I'll probably like to be able to do something like @list.=sort(). But that's largely due to a more generic built-in (non-OO) sort that will be available from the core, using callbacks (such as sort in perl5).

Ugh. Developers who have to be "motivated" in such a childish fashion ought to be fired.

The happy medium that I've found is to write new subs which I use in all future code, while leaving the old code alone. To use your database example, I would start by writing a great new connection sub, and then I would use it in all of my future code that needs to connect to the db. If the new sub isn't functionaly much better than the other old code, maybe I'll leave it at that. (I'll still be happier because in my eyes the code is better organized and easier to maintain, but I don't have much of an argument for spending any time rewriting the old code.) Maybe I'll eventually add better error reporting, retries after failed connection attempts, logging, and other improvements to the sub. At that point I'll have a good argument for getting my coworkers to use the sub, and maybe even a justification for spending the time to retro-fit it into the old code.

I totally agree that it is sometimes best to leave code alone. I've become much more "if it ain't broke" the longer I've been coding. I hate the idea of "starting from scratch." I know it is prone to failure and you have to refix all the bugs you spent hours fixing in the old version.

Of course, sometimes the code is just so clunky and horrendous, it needs refactoring NOW. I guess this would be the argument for maintainability.

But your method sounds pretty interesting - to add the new stuff, but leave the old alone. The dangerous thing is if someone else needs to update the code they have to update it in two different places or risk having different behaviors depending on which code they use. That of course depends a lot on communication, documentation and so forth. I guess I still am enough of a change-happy person to argue that the new code should replace the old as well.

rachel

So I've chatted with some friends about this node - and one of them recommended mocking. I kid you not.

The argument seems to be that if people are resitant to change, pointing out the the fact that the downsides to to 'staying the same' are just as big -- if not bigger than 'changing', might help. For maximum effect your code has to be better than the current stuff. And the bigger your 'pro change' group is the stronger the peer pressure is :)

It can also be useful to point out that you're a perl programmer, and you intend to use every possible feature and methodology to be the best programmer you can be. If they don't want to do the same that's fine by you, but they shouldn't get in your way.

In detail: to me, it sounds like the problems you are dealing with are all due to complacency. If you had half as many coders, you wouldn't have time to write three separate systems. Developers, myself included, often don't work well without some form of external pressure. Constant awareness of the imminent doom of my company is one thing that works well. Just generally being understaffed and overworked also works. If you give me a sense of time and job security, I'll happily go off and overbuild all kinds of systems, tuning them to work exactly the way I think they should. So will my coworkers, and we won't feel like combining efforts too much because we're too intent on our own endeavours, and there's no pressing reason why we should -- in fact, it's probably better to get things right in such a situation.

Of course, in truth whenever you're feeling relaxed like that, you're probably wrong. (Ok, so I'm from the startup world. Maybe it's different in the huge dinosaur companies.) Odds are that you're cruising full tilt at an unseen iceberg, and by the time you notice it, it'll be too late to throw all of the excess code overboard. Instead, you'll suddenly realize that all of those wonderful systems you leisurely built are falling to pieces when you start scaling them or begin applying them to the actual (and somewhat unexpected) problems that you really face. Which leads me to...

Step 2: Hire everyone back and have them write tests and automation infrastructure.

You commented that you now realize what a sorry shape your code base is in -- poor tests, lack of documentation, no code reviews, etc. Don't worry too much about it; anyone who looks honestly at their own organization will probably see the same thing. Even if they've figured out how to aggressively write tests or do code reviews or whatever, in most cases that just means they've lost sight of other things (or are in process deadlock, which is a whole other topic.)

So if you combine the two observations that your code base and processes need some work, and that you wouldn't need so many developers if you shared more code, then you inescapably realize that you have bandwidth to spare for writing tests. Or automating deployment, instrumentation, testing, load testing, documentation, or whatever. Of course, the people who are stuck with those tasks are going to quit, so...

Step 3: Spread the love

Now you just have to combine tasks so that each person is doing both development and testings/automation/documentation/whatever. You'll prevent people from getting burned out, and the coders will be incented to make things more easily automatable, testable, and documentable.

Of course, it would be better to skip steps 1 & 2 and go straight to step 3, but in all fairness I still have to mention...

Step 4: Realize that my post here is useless because it only describes the way things ought to be, not how to make them that way.

The only last thing that I'd like to point out is that I doubt the dichotomy between the "don't fix its" and refactorers is terribly relevant. I think both groups are suffering from the same illness, namely complacency. The "don't fix its" are complacent in thinking that the existing code is good enough, even though it hasn't been sufficiently tested and reviewed, and probably hasn't been stressed much for its adaptability. The refactorers are complacent in thinking that they have the time to spend tuning and fixing and tweaking. It doesn't sound like either group has enough data to knowledgeably choose one perspective or another. That data can be acquired from code reviews and test harnesses and performance data and automation suites. And don't forget trial by fire.

A lot depends on your coworkers and the work environment. For instance, if your fellow coders think that original work consists of taking someone else's code, deleting the comments, then adding their name, I wouldn't count on cooperation to take off. A lot things happen because people feel the need to protect their jobs.

Some companies have coding standards regarding style. I think that's a good policy, as long as the style imposed is not very, very strict and has been well thought.

How do you get it so that everyone doesn't just rewrite the code

Where I'm working now we have an internal Wiki with a section on coding. Code for connecting to an existing database, for instance, is already posted there.

The "If it ain't broke don't fix it" policy is a very good one, because fixing things (and remember that these "things" are often untested) has a tendency to brake them down.

Here's my $.02: start settling some standards, with the help of others, but don't try to do everything at the same time nor fixing things that work. For instance: do design a new database connection routine, but don't put it on working programs. Instead, put it on the new ones or on new versions of the existing ones.

Also, don't forget that people have feellings too... :-)

Very few of us have any private sector experience or academic training in computer science. Most of the coders are trained as scientists, who learned to code along the way. Now, I want to say now that one doesn't need to have a degree in CS to code well, but more of that most of the coders here have learned to code in an environment without thinking about things like OOP or abstraction. And nobody really seems to value elegant code or even understandable code.

It would be nearly impossible to ever have a coder-type person in charge of everyone, because people in charge need to bring in their own funding, generally scientists. Or each project would have to be willing to chip in to fund a lead-programmer/software architect type person, which isn't going to happen in these lean times. And of course, once you are in , you are basically in for life. I must be the only person who is limited-term on the team (i.e., could actually get rid of), and I haven't mentioned, am the youngest and the only female coder. Which probably doesn't help when I am trying to convince guys 15 years older to try out my code.

Speaking as someone who started as a scientist, research isn't particularly efficient. Fairly often you have to patch things together just to get results.

I do think though that you may be able to make a case for standards and documentation because if you use public funding, you owe it to the taxpayers. If part of the grant requires that code be placed in the public domain at the completion of the project, there might be more incentive to improve.

Think you're bumping up against the glass ceiling?

thanks for the recommendations. I hadn't even heard of Perl Medic before but I love the title!
Rachel