We don’t need no steenkin’ code reviews!
posted in Computers, Work |Well, actually, yes we do.
A few weeks ago, I wrote about my little mystery hunt trying to figure out why the vehicle reservation system in my department of Small Mountain University was on the fritz, how I discovered that the unique identifier for each reservation was limited to four digits by Nice Young Intern, and how sometime in the past few months, we had hit 9,999 and the reservation numbers started all over again at 1, causing all sorts of funky errors.
My readers in the biz were appalled. "Where was the code review?!" they proclaimed.
Yah, well. (OmegaMom looks aside, shuffles her feet, coughs a bit…)
I love working at SMU. I really do. I started in the ITS department, got chopped in the Great Layoffs, took a (much less remunerative) position as an administrative assistant while waiting for IT jobs to re-appear, and then got my position in Current Department when the job market started warming up again. The atmosphere on campus is collegial. There are lots of cool folk doing lots of cool things on the academic side; there are lots of cool folk doing lots of cool things on the ITS side; there are lots of cool folk doing less cool but immensely important things on the business side, and almost everyone I’ve worked with at SMU has been intelligent, interesting, fun, and good to work with. (I can think of two exceptions over the past nine years, that’s all.)
Anyway, in the ITS department, since we have lots of folks there, many ITS things were (and are) done by the book. Good coders, good reviewers, good interactions between everyone. But there are only so many ITS folk to go around, and those that are tasked with helping on more complex projects outside ITS are booked solid for a year in advance.
Out in the departments, there are IT folk who are hired as departmental support. Itty bitty departments have to make do with no-one, or sharing someone with a few other itty-bitty departments. Bigger departments get one or two. Really big departments get their own geek squad.
Each of those support folk have to handle a wide variety of different issues. There’s day-to-day support: Figuring out why JoAnne’s email suddenly disappeared. Helping Dr. Professor Jones stitch together a master document and sub-documents in Word (and trying to explain that master- and sub-documents in Word have a really bad reputation for getting corrupted and frying your entire 417 page manuscript). Updating web pages. Maintaining small databases. Developing interfaces to bigger university systems, or maintaining old interfaces that have been just chuggin’ along for many years but need a tweak or two now and then. Arranging repair for old equipment. Buying new equipment. Figuring out equipment budgets for the upcoming year. Buying color toner when something needs to be printed in color RIGHT NOW! Crunching numbers in spreadsheets. Putting together pamphlets or brochures or quarterly newsletters. Getting new people set up on systems and into the university system. Running local servers. Maybe running computer labs for students and staff. Providing down-and-dirty training.
Rarely a dull moment. Always fun to help people. Good to get to know folks in all aspects of the higher education biz.
It’s sort of like juggling. There’s always something that is urgent. Typically, the urgent stuff is related to ensuring that everyone in the department is able to do their work. Then there are the bigger departmental projects…which get done in and around the "making sure everyone can do their work" everyday stuff. You’re catching the errors on this database while crunching the numbers for that report to the board while uploading PDFs to the website while figuring out why the network has gone down for the people in room 219 while…
What ends up happening is that whoever gets handed the bigger project just bulls in and does it.
Like the project Nice Young Intern worked on.
It gets done, it gets tossed up, people who are chomping at the bit to get to use the project start working on it (ostensibly as testing) and then suddenly it segues into being used. And rare is the chance to get someone to give your code a review.
I’m pretty sure Johnny and SpaceMom are shivering in their boots at that mild paragraph. Where’s the project outline?! Where are the specs?! Where’s the test plan?! Where’s the code review?! Where’s the iterative process?!
I know, I know. At times it bothers me, too. But y’know what? It’s really fun work. You get to be a jack (or jill) of all trades. You get to help people. And all of these "bigger" projects are really, in the course of things, small potatoes; they’re "big" in relationship to the day-to-day stuff at the departmental level. It’s not like the small army of coders and testers and code librarians and project managers handling a Truly Important Project like the online education program or the accounting program or the human resources program. Those projects are vital, necessary to the lifeblood of the university as a whole. They’re handled by ITS, they’re treated like good software projects should be, they take time and money and people and organization. Those projects get code reviews out the wazoo. Smaller projects that ITS takes on, handled by one team or another, also get the software project treatment. But projects handed out to departmental support folk? Those get dropped on the desk as a "Y’know, it would be nice if we could do x, y, or z. D’you think you can pull something together in two weeks?"
NYI’s project started that way, and my predecessor knew that it would probably not get done in any decent amount of time unless she borrowed a student from the CS or CIS programs. It made a good summer project for NYI, and he did think it through, provide specs, program it, and get it up and running. Since he specified only four digits for the reservation number, I’m thinking that people talked it over and figured that the program would be replaced long before they needed to worry about it. Sort of like Y2K.
But code review? What a luxury that would be!
