blog.philcrissman.com

When I decided that I wanted to change my career and “go into computers”, I had a very limited exposure to computing.

Well… I should qualify that. It’s true, I had used DOS so much in high school (before there was Windows) that I preferred DOS to the Macintosh of that day, wrote my own autoexec.bat files, and in fact had a copy of DOS, Pascal, and Moria on 5.25” floppy disks that pretty much went everywhere with me. At the time, many DOS PCs did not have hard drives; you loaded the OS from a floppy, then it ran from memory and you put in some other disk with your files or other programs on it.

And I took a class called AP Computer Science which spanned 2 years; the first of which was all Pascal, which I found that I loved, and the second of which was all theory, during which I tuned out and drew cartoons in my notebooks (I was 17, what can I say?).

But after that… after high school, I really didn’t touch a computer for years. I didn’t own one, didn’t know many people who did. I didn’t really edge back toward computing until 1996 or 97, when I think I got my first email address (a Yahoo account which still accumulates spam).

So, when I decided to go into computers, it was by no means as a result of my casual familiarity with all things computer-ish. I had some distant background, but everything current was obscure to me. We had a PC at home which ran Window 95; and this was 2001.

I figured I’d need an edgemecation, so I looked at the curriculum of the local community colleges and saw “Computer Science.” That must be what I’m looking for, I thought, so off I went. In the meantime, I got my foot in the door by reading an A+ book cover-to-cover, getting a helpdesk job, and teaching myself to program on the web.

In the past few years of being in IT departments (both at small businesses and now at Oracle), in the various computer science classes at universities, and reading just about any and everything I can, I’ve noticed a few things.

For starters, as is well known if you are also in either computer science or software development, Computer Science as taught in schools does not seem to have much in common with “real world” software development. For this reason, you also see a major which overlaps somewhat with a Comp. Sci. major’s requirements: usually called MIS or CIS (Management/Computer Information Systems) or something along those lines.

It’s like Computer Science, only practical.

As it turns out, I’m more interested in Computer Science than Managing Information Systems, in general, so I think I made the right choice. But thinking of things like my past few articles, I’m trying to determine just why that is. (Though, honestly, “Managing Information Systems” just sounds incredibly boring.)

Interesting vs. Practical

Computer Science (my take, at least) is interested in structures and methods; what’s efficient, what’s interesting, why it works, and so forth.

More vocational programming (and hey: I am entirely in favor of developing software for a living) is much more concerned with processes, designing large systems, keeping code maintainable, being able to communicate what code is doing, UML diagrams, patterns, and so forth.

Now; I think there’s a lot of overlap there. But there are some big differences. Someone with a computer science mindset might be very interested in Lisp or Scheme (or Haskell, or Io, or Scala, or Ruby, or Python…) simply because of how they work, how they are different, and so on. A more pragmatic/vocational approach would have only one question: will anyone give me a job programming Lisp (or other from that list)? No? Okay; not interested.

In the second mindset, Ruby and Python only become interesting when you read that companies are actually using them, and paying people to write in them. In the first mindset, they are intrinsically interesting. Again, this is just a personal observation. It may be that most Computer Science students are really more interested in J2EE programming for Fortune 500 companies and are just taking Comp. Sci. because that is just how you do it.

But J2EE or whether we are interested in having good careers (of course we are) is not the point I’m trying to reach. The point, which in one way or another I’ve been writing about for the last few posts, is the dichotomy between the “clever hack” approach versus the “Great Wall Of Best Practices” approach, to programming in general.

Without re-treading too much old ground, one approach favors clever, neat, or elegant solutions. They might be shorter, or trickier, or more efficient, or merely unusual. The other approach favors… well, whatever is the least risky, basically.

I can understand the necessity of most best practices. If you are writing software that will be enormous, that will handle huge amounts of data, data which may be incredibly important to many people (people’s banking or medical records, or airplane routes, for example), there is a much greater amount of risk involved than if you are writing a new blog platform that you will use and frankly you don’t care if anyone else ever uses it or not. In the first case, failure of the software could be catastrophic to hundreds of thousands of people, up to and including loss of life; in the second, it’s a minor annoyance and you fix it when you have a chance.

So, if I’m a large company commissioning the creation of a huge, critical software project, I’m going to appoint someone to manage it, and I’m going to make it very clear that they are responsible for returning a product that works as advertised and will not wipe out everyone’s bank account or cause two planes to crash into each other. Oh, and also on time and under budget. User friendly? Only if you have time.

So now this senior project manager is going to have a team of people working on this software. She’s going to want batteries of tests run, procedures followed, and code that can be maintained. What if five of the best developers quit and become consultants for IBM? Well, someone had better be able to come in and continue working on their code, so it had better be readable, so do it like this....

...And we spiral into the process that, if successful, creates the Enterprise Software we know and loathe today.

And yet, I believe… I want to believe… that clever hacking can be kept alive and thriving in the midst of all this. I’m not sure that I can answer exactly how this can be done, but here’s the reason I think it can:

At the core, all of the problems faced by the development of Enterprise software, are still interesting problems, the kind that can engage someone in the clever hacks mindset. You need processes that allow code to be tested, maintained, that will be efficient, will allow for possible changing APIs of dependent software, changing platforms at some point in the future, changing file formats…? These are all potentially interesting problems. There have to be solutions that don’t involve sucking all the life out of the development process.

So even though the massive, test-driven, process-centric world of Enterprise software often seems at odds with the quick and dirty, use-the-language-of-your-choice, elegant-hack world of programming for fun, I don’t think it needs to be.

For an example (and maybe for a future post), I think this is part of the reason Rails has exploded in popularity over the last few years. It pleases (generally) both crowds. It incorporates all sorts of best practices and design patterns, while still being one big clever hack, using Ruby no less. I don’t think Rails is the be-all-end-all Ultimate Conclusion of this sort of thing, but I take it as a good example that, yes, you can please both camps.

Happy hacking.