(It's long and it's preachy -- but I hope you enjoy it)

JFK speaks his mind about programming techniques

That great software programmer John F. Kennedy once famously said:

"Ask not what your software project can do for you - ask what you can do for your software project."

(Few people realise the 'F' in 'JFK' stood for 'Fortran'.)

I'd like to go one step further than JFK, and look at both sides of the deal: What you can do for your project as well as what the project can do for you.

In putting this list together, I'm going to steal liberally from two classic articles "The Joel Test" and "The programmer's bill of rights"

Here's the quick overview...

What can the project do for you?

First up we have a bunch of items along the lines of "I expect -- maybe demand -- that management will provide me with..."

1. Two monitors
2. A fast PC with a crapload of RAM
3. Choice of mouse and keyboard
4. A comfortable chair
5. Quiet working conditions
6. Internet unlimited
7. Freedom to install software
8. The best software
9. Good coffee
10. Sensible working hours
11. Separate Environments for dev, qa and production

What can you do for the project?

But it's not all "take take take".

The other side of the equation are items along the lines of "I am committed to ensuring that these practices are performed..."

1. Source Control
2. Continuous integration
3. Track bugs
4. Unit testing
5. Code analysis
6. Continual peer review
7. Peer training
8. Keep yourself up to date
9. Learn to Communicate with non-technical people
10. Refactor!
11. Passion

JFK asks management for a second monitor

Part 1: What can the project do for you?

Two monitors

The research is in. It's worth ten times its price. Give your dev two monitors.

A fast PC with a crapload of RAM

There's a messed up philosophy-- a kind of offshoot of the 'eat your own dogfood' school of thought -- that insists developers should have the same desktop rig as end users. This is nonsense.

End users aren't running three virtual machines, a local database server, three instances of visual studio, and two instances of blend. Devs need a hot rig with massive RAM. Anything less is ridiculous.

Choice of mouse and keyboard

Want to see a perfectly sane developer go nuts? Give them a bad keyboard. I have anecdotes around this topic... terrifying anecdotes that would turn your hair white... but the people involved are all still alive and i can't spill the beans. Trust me. Don't f*** with a developer's keyboard. Bad things happen.

A comfortable chair

This isn't just a programming thing of course, it's crucial for all office workers. The productivity loss from one screwed-up back could buy Herman Miller chairs for the whole company.

Quiet working conditions

Four-walls and a door might be too much to ask, but at least organise the open spaces in ways such that the shouty/squealy-teams are separated from the thinky-teams.

Don't put marketing next to the devs. Don't put the help desk next to the devs. Don't put the angry shouting Glengarry Glen Ross-style sales team next to the devs. In an open space, use baffles and greenery to isolate the noisy teams. Consider the different Yerkes-Dodson requirements for optimum performance from each team.

JFK's workstation includes a state of the art console and a swivelling chair. Uniform: relaxed

Internet unlimited

Consulting has shown me some pretty weird scenarios. I've worked at places where they insisted that 'contractors don't get internet access' and i've seen plenty of places where there are heavy handed website filters in place. 'This site is banned because it looks like a blog' -- for example, WTF? Even worse: "sorry, you can't use google, our company policy is that we use yahoo." WTF? If you choose to work with people, put some trust in them. Monitor them if you must (and tell them if you do) but don't put roadblocks between them and the obscure information they're trying to get their hard-working hands on.

Freedom to install software

Group policies, S.O.E.'s, limited user privileges -- these are all good and helpful things that IT departments need to keep their own sanity. I get it. I know. But let the devs break out of the box, please. Tell the dev's that they're on their own if the stuff they install causes problems. They have to fix their own messes -- but give them the freedom to install whatever dinky little weird utility they need from one minute to the next.

There's plenty of specific tools I've installed to use just once in my career, and then never needed again.

Having to fill out a series of forms on such occasions is a waste of everybody's time.

The best software

Why for the love of god is .net 1.0 still in use? Why are you advertising for a VB6 developer? Why do you make developers manually track the differences between two databases? Why do you let developers roll their own code generator? Because you're a stingy short-sighted fool I guess.

Good coffee

What is this crap we're drinking? Nes-frickin-cafe granulated food service blend? You had better be kidding me. Get me a goddamn macchiato. Now. Then back the hell away and let me write my goddamn code.

(Image courtesy of Rands in Repose)

Separate Environments for dev, qa and production

You can't afford testers and you just want me to fix it in production, eh? That's awesome. That's great. Next time the dentist is drilling out a cavity in your mouth, I'm going to tell him "This is an urgent operation. Let's not waste time on X-rays. Just start drilling, you're bound to hit something that's rotten. And let's save a few dollars and cut out the anaesthetic altogether."

Part 2: What can you do for the project?

Source Control

If they don't have source control -- you create a subversion repository. If they do have source control, but they're using VSS, you can move them onto Sourcegear vault. (It's an easy transition and it overcomes most of VSS problems.) If they're using vault you can move them onto subversion. If they're using subversion you can bump them up to mercurial. If they're using mercurial you can push them into git.

Okay -- don't change things just for the sake of changing them, but make sure you're using the best source control solution available to you, you're using it well, and everyone's using it.

Continuous integration

If there's no daily build, then put a daily build in place. If there's a daily build, them make sure it starts with a clean environment (no cheating) and make sure it builds everything, not just a couple of things. If the build is good, then make it continuous -- make it happen on every check in. If the build is good and continuous, make sure the communication lines are clear -- everyone can tell the status of the build at any moment. If all that's in place... well move onto another point.

Track bugs

Email is not a bug tracking system. You can't run queries over email. Email slips through the cracks.

If there's no bug tracking system, set up a shared spreadsheet. If the only bug tracking is some crappy shared spreadsheet then use sharepoint, or install Jira. If the only bug tracking system is sharepoint or jira, then install lighthouse. If the team are stuck on lighthouse then purchase Fogbugz. If TFS is available, make sure the workitem tracking is well configured and well used. If checkins aren't associated with bug numbers, make it so.

Build whatever tooling you need, above what the products you use offer, to ensure that the bug tracking works for you.

JFK asks the users for feedback on the proposed entity-relationship diagram

Learn to Communicate with non-technical people

Stop baffling them with bullshit. You don't do it on purpose (well, not usually) but you still do it way too often. Stop using technical terms with non technical people. Find the simplest way to state your ideas. Leave implementation details aside. Dummy it down. The end user has a full life of stressful issues all their own, without having to translate into your crazy mumbo jumbo.

Unit testing

If there's no unit tests, identify hotspots, start slow.

Start with regular expressions. Never trust a human's ability to write regex. Every regular expression needs solid unit testing. Focus on critical business logic. Focus on stuff that matters. One by one, knock them down. Every gain you make is a victory. Feel free to celebrate.

If unit tests are already included, but they're not part of the build, put them in the build. If there's a good amount of unit tests, then get code coverage metrics into the build. Set interim goals -- increase coverage by two percent within a week. And then increase it some more.

Code analysis

The build is running -- but how bad is your code? Run FX-Cop on every build. You're running FX-Cop? Then fix your problems. Identify common problems and fix them in batches. Update the list of exceptional terms (this is like adding new words to a spell check dictionary). You've done all that? Run further automated analysis. Fold n-depend into the build. Oh and before I go on... please, for the love of god, treat warnings as errors. Clean up that dirty code you're shovellin'.

JFK dressed as a US president

Continual peer review

You want to create a workplace where you understand and learn from each other's code, constantly. The trick is to make it non-confrontational. If it happens rarely, it's going to seem confrontational -- but once it happens routinely it will be an understood part of the workplace. Some places use code reviews prior to every checkin, some places use continual pair programming. Use what works best for you, but make sure code ends up being owned by the whole organisation not just the individuals.

Peer training

Teach each other. Discuss code, discuss business. Talk to each other. Say hello to each other in the mornings. Train each other. Organise lunch time brown bag sessions. Attend user groups. Talk at user groups. Be active in your community.

Keep yourself up to date

Don't let your skills stagnate. Don't stick to what you know -- put yourself outside your comfort zone as often as possible.

I'm not saying you should learn every shiny new technology you see -- but I am saying that you should take responsibility for your own continuous education. Moaning that your employer doesn't send you on courses is ridiculous.

Refactor!

Fix the little things. Fix them often. Improve method names. Improve variable names. Be consistent, be clear. Extract methods. Focus on those terrible long methods. Reduce cyclomatic complexity. Get a second opinion. Talk about your code. Little fixes add up.

Passion

No -- you don't have to go too far with it. You don't have to take everything personally. But you've got to care. You've got to give a shit about the code you write and the people who use it. If you don't care about it, you're never going to enjoy it properly.

Yes, it's a frustrating job, where little details threaten to derail the entire project at every moment. Yes, you are surrounded by silly ass-hat clowns who don't understand a thing about what you are trying to achieve. Yes, it's tedious and gruelling and it makes your brain hurt. But you've got to care dammit. There's no shortcut on that one.