I was thinking today about stuff I’d like to actually blog about, and since this is what I do for a living right now, I thought I would start with something easy. Programming. Yeah, yeah, easy for me, right? Basically, I sit in front of a computer all day and make it do my bidding. Don’t worry, I only use my powers for good (right now anyway, muahahaa!).
The project I am on and have been on for the last several years runs north of half a million lines of code across 23 projects right now and I am one of two people that actively work on it. At this point, you could go over and browse through Dilbert strips (www.dilbert.com) and probably begin to understand about 90% of what I do on a day-to-day basis. Really, I’m not lying about the Dilbert thing.
There are a lot of aspects to what I do. For most projects we get a set of requirements from marketing/sales/support that detail out what needs to be added, editing and/or removed from the next release of software. In this case I would then take that requirements document and spend a week or two writing up a “Software Technical Specification” that outlines and details what we are, and are not, going to do to meet those requirements. This includes mocking up new screens are showing changes to existing screens along with talking about what work is involved, what code will need to be changed and sometimes, how long I think it will take. Estimation is a big part of what I do. Everybody always wants to know how long I think it will take to do something, then when they think that is too much time they ask what can we pull out to get this by X date and we negotiate back and forth till everyone is happy-ish. But I digress, this tech specs tend to be anywhere from 10 pages to 50+ pages (yes I have personally written a document that is over 50 pages long). The spec goes through a review/negotiation process, some rewrites, screen shot tweaks, more review, rinse, lather, repeat as desired.
Once the spec is given the okay then we write the code. This part is the most fun for me and generally the smallest part of the product release. We write the code, update unit tests, update the build system and then roll a release candidate to quality assurance (QA). Now, unit tests are small, focused tests that exercise specific pieces of the code and make sure that from build to build we developers didn’t break any core functionality in the software. The build system is like a computer based assembly line, code goes in one end and the thing you install on your PC comes out the other.
Once QA gets it they/we decide on which test scripts they will use to exercise the changes that were made and then they go off and test our fixes and changes. Generally speaking, these changes either work or they don’t. If new issues are found because of a change then we update the tests, fix the code and go around again. We do this process until we are satisfied with the result.
I want to take a moment and make something very clear to those that don’t live in the software development world. ALL software has bugs. ALL software companies know about some or all of said bugs before each release. ALL software companies knowingly release software with known issues/bugs in them. It’s the nature of the beast. Hopefully what I just said wasn’t like the time when you found out the Tooth Fairy wasn’t real. Sorry, that’s just how it is. Software development is an iterative process. Granted some software companies are better about making sure that they don’t release with major defects and that the product only ships with bugs that happen if you stick out your tongue, sit on the keyboard, turn your monitor sideways and happens to be on the fourth Tuesday during a full moon. Most people won’t see these types of bugs, those that do are generally offered workarounds or patches that take care of the situation until the next release.
Moving on down the process, after QA generally comes BETA. The “B” word. This is where you get either your most cranky customer or some of your best customers to take it upon themselves to install this new software upon their systems so that it can get some real world use. BETA feedback is gathered and new issues or workarounds are addressed and we either go around again or we move on to final release.
Pretty much at this point, my involvement as a major player in the project ends. Change orders are made, lost, rejected, remade, reviewed and so on. Once production is ready for it they ramp up and get everything in place and we wait for the release date. By this point we are generally deep into the process on another project or the next release and we go around again. Like the circle of life, only with 1’s and 0’s.
My colleagues and fellow programmers will probably note that have greatly over simplified the entire process because they want more details. That’s how engineers are. I was a film/marketing/web guy first, then I got converted to the dark side. I like to think I can still cross back over into the light but there are times when I am reminded that I am also an engineer. If you enjoyed my take on programming check out www.joelonsoftware.com, Joel is a guy who has been through it all and still wants to write software. He is quite enjoyable to read. Check out Dilbert, too, seriously, it’s scary sometimes.