Posted by | Posted in Software Development | Posted on 09-07-2005
The past few years at DigiTar have been a heck of a learning curve for me as a developer…er…manager of developers. You graduate college with a CS degree and at the world you go…happy as a pig in stuff. Think you know everything you need. What you don't realize is that you don't know anything. Sure you know data structures, and you can program in 5 different languages. You might even have built some pretty complex programs (or so it seemed at the time). But you don't know what you're talking about. Trust me.
You've been trained as a carpenter essentially. A really basic carpenter. Sure you know what a hammer looks like and you've framed up a door here and a wall there. The problems with what you don't know come to the surface when you go to build your first house. Or better yet, your first room. Up go the four walls, a door and a window…but the doors don't quite hang right and darn…you forgot to put in conduit for the electrical.
Nobody at “carpenter school” ever took you aside and showed you how to think about building a room. Best practices for hanging a door…laying out a window…nope…you haven't got any of that. The root issue of all the toe stubbing you're doing at your first job is that nobody ever taught you to build a room on paper first. So what do you do? You start building the room with wood and nails, and you quickly find that mistakes made in that medium are really expensive. It takes a lot of work to recover from the crooked doors. As for the bad framing…well you just gotta rip it out. The cruelest irony is that you don't know any better, so you probably spend a lot of years before somebody shows you a better way.
So what am I getting at with all the blathering? Computer Science programs don't teach their students how to build software (software engineering programs are a different story). They teach them how to be glorified hobbyist programmers, and then throw them into the buzz saw that is experience. For me, it was amazing how much more effective we became in a 6 month period by learning four best practices that school never taught me:
- Use version control.
- Track your bugs formally.
- Fix bugs before writing new code (you'll never hit a schedule otherwise).
- Don't write a lick of code until you've written a functional spec.
There are a few other important lessons (i.e. unit tests) but those are the four that made the biggest impact. To paraphrase Steve McConnell, CS programs turn out scientists not engineers. Scientists build stuff that works in the lab, and is too darn frail to live in the real world. The software development world expects CS students to be engineers, but they're not. They don't receive any of the “thinking” training or apprenticing that would make them engineers. I personally owe a debt of gratitude to Joel Spolsky and Steve McConnell for writing books that filled in the gaping sink holes in my education.
Another thing to keep in mind with this whole carpenter metaphor is that its actually a lot worse than that! As a software developer, you can't just be a carpenter. You're also the general contractor. Everything from the framing to the electrical and the plumbing….you're up slugger!
It seems to me that the CS program I went through (no I won't tell you where) needs at least two new courses. The first needs to be taught right after they teach you the first programming language, and simultaneous with your data structures course. Let's call it “Coding Habits” for total originality. Coding Habits would teach you how to lay out your program's functions, classes, etc. in English pseudocode before you do real code, and how to translate your “English” into real code. It would basically need to cover a slew of “best practices”. A course like that would have saved me a lot of hours in the rest of my CS courses…and its absolutely essential for doing professional software development. As for a course text, I'd suggest Code Complete. Take a look atTom's Developer's Nightmare blog for more on this topic. Tom is one of our very own, and has some very definite opinions on the subject.
The second course you need is the one I'm more qualified to pontificate on…let's use the moniker “Software Projects”. Software Projects would work best as a second-semester Junior-level course. It's basic premise is how to go from an idea to a full-blown project. Topics would include writing, crystalizing your team's ideas, dealing with stakeholders (such as users) to winnow features, and the whole functional spec process. People and time management would need to feature prominently. Personally, I'd probably teach off the Joel Test. That's just me. There's certain things that only experience can teach, but let's give CS students a fighting chance.
All universities hope their graduates reach some sort of managment responsibility. They need tools to do that. Heck, if a student's first interviewer is worth their salt, he'll ask a few interesting questions regarding how they think about software development. The answers will be drastically improved after a course like Software Projects. At minimum the answers will be more interesting than “Uh…object-oriented programming rules!”
Any CS program that does a better job of training “engineers” instead of scientists does their students a great favor. They'll get better jobs, and the school will get more recognition…which feeds back into getting better jobs. I'll make this offer to any school amenable: DigiTar will teach an abridged version of both these courses over the spring break of your choice. You pick the students for each course. We'll teach them. In fact, we'll offer the top students jobs. Personally, I'd rather see them learn what they need to know while they're still in school, and before we get 'em!