Many people assume that once they have a bachelor’s or master’s degree in computer science, they’ve got everything they need to succeed as a professional. But it takes a couple of years struggling in the early part of your career to realize that, in fact, there’s a lifetime of learning ahead, and most of it doesn’t (directly) deal with computer science.
College does a great job of laying a theoretical foundation to start from and giving you a common technical vocabulary to communicate with others. In college, you develop small, focused programs specifically designed to explore a certain concept. In some cases, you even work for a few weeks on small teams. But no matter how big or long those projects may seem in college, they’re nothing compared to the scale of the software you’re going to end up writing in industry.
Interesting things happen with scale. I mean scale in many different ways: large code base, large user base, large developer teams, large time horizons, large amounts of money at stake, etc, etc. Each of these big gorillas bring with them their own challenges and their own tools to deal with those challenges.
Let’s start with source control. When you’re just working on a 3 member team for a couple of weeks in the school lab on a throw-away program, using something like CVS might seem like more of a pain than it’s worth. And what your professors won’t tell you is that in that scenario it really is more of a pain than it’s worth. But if they’re good professors they encouraged you to use it anyway, just to get used to it.
Why? Try imagining that project stretching on for years instead of weeks. Imagine dozens of contributors coming and going. Imagine trying to share a code base with people in a different building, different state or even different country. Imagine trying to eyeball every one of literally thousands of files to see what’s changed each time you want to compile a release. Now you start to get an idea of why source control is important and why, literally, people have written
entire books about version control.
But back up a minute, what’s a “release”? When you’re in college, your development cycle consists of two phases: 1) write and test the code in the lab, and 2) email (or whatever) it to your professor. Things get a lot more complicated in industry, though. If you do internal software development, then when you finish your code, it’s going to move into a production environment where it will immediately start effecting real people, real business processes, and real money. If you work for a software vendor, your code is going to be packaged up with a whole marketing blitz, rounds of support training, and installation at customer sites where it will…start effecting real people, real business processes, and real money.
Wait a minute, what’s a “production environment?” In school, you do your coding in the same lab everyone else is using to do who knows what. In industry, (smart) companies have strict divisions between environments. At a minimum, they have a development environment and a production environment. Development is where you do your coding and production is where the company makes its money. There’s no end to the environments many businesses will have:
Build: a clean environment where you sanity check that you didn’t forget to check something into source control and that your code plays well with everyone else’s code.
QA: when you think you’re done coding, you install your code in the QA environment and test it some more, usually integrated with everyone else’s code
UAT: usually the same as QA, but sometimes on its own. This is where you turn your creation loose on non-developers so they can test out the ride (and find the bugs you didn’t find)
Production: where the money is made. Often, you will be physically prevented from accessing this environment and will have to rely on a different team of people to install your changes to it. At a minimum, you will have to fill out some paperwork or go though a ticketing and approval process to install your changes here.
BCP: stands for Business Continuity Planning. An exact copy of your production environment that’s hosted somewhere physically separate from your production environment. If you have a component failure (ie. a database goes down, hard drive fails, network fails) or if the city your production environment sits in is vaporized by terrorists, you fail over to the BCP environment. Think businesses don’t plan to that level of paranoia? Think again.
That’s it for part 1 of this series, ahead in part 2 and 3: some technologies and development methodologies you didn’t learn in school.