Find the documentation for the X10 controller. Figure out the protocol it wants to speak over the serial wires (starting with pinout, baud rate, software v. hardware flow control). Connect the X10 controller to the serial port (the USB thing). If you are a pessimist, you could now use a voltmeter to make sure the hardware is connected correctly, check the voltage levels on the TxD and RxD pins, and whatever hardware flow control lines are needed. Let's be optimistic, and assume that the hardware just works out of the box (with modern 9-pin connectors, I find that to be true 80% of the time). If the protocol (the character sequences that need to be sent) are halfway suitable for being typed and viewed by a human, then use some terminal emulator program (I'm fond of miniterm.py, but there are many others). Configure it for the correct baudrate and flow control, enter it. Send some command to the device (most devices have a "hallo" or "ping" or "what is your identity and version" command, and look at the output. Often, these protocols are a bit binary, and require stuff like "control T to start the command, and a "*" at the end, no newline". Usually, you can put your terminal emulator program into some mode where your outgoing traffic is echoed, and all the incoming traffic is displayed in hex instead of characters. This allows you to verify that some communication is going on.
Once you are at this point, find your favorite programming language (mine happens to be Python), and download/install/use a serial communications package for it (for me that's pySerial). Write a short program that sends a short command to the device, waits for the reply, and decodes it. Once this works, the rest of the control is a question of patience: Design and write code that sends more and more commands, and decodes more and more responses. Over Christmas I did that for two new serial devices (an Omega PID controller, and a RedLion voltmeter, both with serial ports), and each of those took me two or three hours only.
As you go along, this will get difficult. Most likely the device is slow enough that you'll want your program to do other things while waiting for the serial port delays (9600 baud means ~1ms per character!), and at some point you'll probably want to be able to catch unsolicited (asynchronous) data from the device. Both will mean that your program will become multi-threaded, and that will require locking of the data structures. This is work, but for an experienced software engineer getting a basic communication thing (asynchronous, threaded, locked, with error handling) should take only a few days for a handful of commands and responses. You are not an experienced software engineer yet; when you're done with this project, you will be.
