My team relies a lot on colour within our code to outline features that need to be worked on (we colour lines of code that need attention). We have a close friend who is colourblind and wants to join our team. What can we do to highlight what needs work without using colour? We have about 25 people on the team that are all accustomed to the line colouring system and we have found it to be most efficient.
One of the developers I regularly collaborate with is colorblind. The issue isn't just that he can't tell colors apart, but also that he doesn't tend to think much about color. He, and other colorblind people, learn to make it a nonissue to the point where color, even that they can tell apart, becomes a bad tool for distinguishing things. We were talking a little bit ago about Xbox games -- some badly written games distinguish what buttons to press by color alone. Even if they choose colors he can tell apart, his brain isn't set up to pay attention to color and differentiate on it.
Your current system is broken. There's no two ways about that. If his colorblindness even raises a question about him working with you, there's something terribly wrong. Maybe there's some learning to work with him (my friend will have to verify colors with us if he does visual design work, for example), but it shouldn't come up at all in the decision making. He can also be an incredibly valuable resource in developing accessible applications by helping you verify them very easily.
Aside from my colorblind friend, one of the big design projects I had in college was a very heavily visual application for a colorblind client. We didn't see it as a limitation, but rather an opportunity to learn. We found an awesome tool called Vischeck that simulated what colorblind people see (all different kinds). It's a good thing to learn these techniques now with your friend who will likely just roll with it while you get on board. If you wait until you have a candidate that you can't hire simply because he can't see the same colors as you do (doesn't that strike you as absurdly silly?), you're going to get yourself into all kinds of trouble.
Now, this isn't to say that you have to do away with the colors. If they work for you, great. Just don't make them the primary method of spreading information across the team, make them an extra additional help. Think of syntax highlighting in a code editor. The code is perfectly readable without it. Even someone who pays no regard at all to color can use the editor with absolutely no issues. The colors are there for the convenience of the people who will use them, nothing more.
I am not a lawyer or HR professional but this quote: "with a team of about 25 people it's impractical to implement a completely different system" raises red flags with ADA rules.
Unless full color sight is a specific requirement of the job you cannot discriminate against the disability of color blindness and must make reasonable accommodations to allow him to work. Impracticality is not a defense in a discrimination lawsuit, though I'll repeat again that I'm not a lawyer.
Something simple like making the colors configurable would suffice, configurable display options is just common sense.
Sound. Shape. Font. Style. Size. Text Comments.
You can't think of these on your own? If you can't come up with alternatives, why does anyone want to work with you?
(Yes. Sound. There are numerous screen readers and adaptive devices for the blind. Numerous. You couldn't find a single one? Really?)
Whatever happened to leaving helpful comments? Really, I would think that just leaving comments like "this needs some work", "this should be refactored", "to be implemented", or "completely broken here, fix immediately" would be a lot more effective than some crazy color scheme. Written comments can be immediately comprehended by anyone (even a blind person, if he/she has a screen reader). Also, you can do it in a regular text editor and not some in-house tool that the new guy would have to learn how to use.
Is this person completely color blind? This is very uncommon; most cases of color blindness are rather specific, i.e. red and green look the same, but all other colors just work. You could select a set of colors that is unambiguous even for specific kinds of color blindness (possibly even several types).
Alternatively, the colors could be complemented with simple symbols (how do you add color to text files anyway?)
You should use semantic markup rather than coloring lines.
Easiest way would be to use HTML:
doFoo(); <span class="refactor">doUgglyThing();</span> doBar(); doBaz(); <span class="debug">makeBug();</span>
And then you let him adapt the stylesheet to suit his needs. Also this is purely textual, so it's suitable for version control.
Or use comments to highlight different sections and then write a small display tool which lets you customize formats. This is probably the best option, because it means all this information is directly in your code base and all can be maintained in one place. Something like:
doFoo(); doUgglyThing();//REFACTOR doBar(); doBaz(); makeBug();//DEBUG
Lastly, a ready to use option would be to use a semantic text editor such as Ulysses. You can tag and mark different types of sections and assign formats to section types. You can also comment different sections and so on. Also it has a HTML exporter (among others), so it's actually quite suitable for writing documentation.
Add an additional system that conveys the same information that your use of colour provides.
This could be:
Or anything else, really. However, the disturbing issue here is that you seem to think that these constitute a "completely different system" - that's not the case - your existing users can choose to ignore them entirely and rely on colours, if they so choose.
Assign each task a numeric rank and keep the list sorted.
Rank Description -------------------------------------------------------------------------- 1 Find a way to make our task list readable by the new guy 3 Gain some rep by asking a question on Programmers 9 Convince the manager that 25-people team might need an issue tracker
Late to the party, but: Color Oracle is a program that runs on your computer and makes your desktop look like it would to a person with any of the different types of colorblindness. Run it with your IDE open, and tweak the colors you use for various things. Very few people are totally colorblind, in the sense that they can't perceive any color differences at all; you might be able to choose a set of colors that works for this person and for your team.
The very simplest thing would probably be to take a few hours and add a new symbol to go with each color (lik3 # with red; @@ for blue, etc) and put it in a comment line near the colored text. This way the color-blind person can just search for all # and find all red lines. He can't scan a page and have color jump out at him, but there's little textual information than could do that for him anyway (color really is a powerful sensory experience for humans).
But I agree that you should probably just begin the transition to an issue tracker; this sounds like you have cobbled together something potentially inefficient (although of course I haven't seen what you have).
It's a no brainer, but really, do not rely a lot on color, on your code.
And in general, do not rely in a mandatory editing system.
(an IDE may be tolerable, but only given enough tradeoffs in term of productivity)
Establishing a proper indenting convention is already quite hard, time consuming, a matter of feuds, and a source of discontent. Mandating color would make most people I know mount the barricades.
From comments I see that you're using a tool that you've developed in house. Given that, the solution is simple. Go through the code line by line and mark every line that impacts the way code is displayed as needing significant improvement. Then, fix your code. The value that your tool provides isn't in the particular color scheme you've chosen or even that the whole team currently uses one scheme. The value is that you can mark up code in a meaningful way. How that meaning is represented should be completely configurable. Think of the job as a welcome opportunity to improve your product.