Today, I came to a realization. I’m now officially an Old Fogey Software Engineer. You know, like those narrow-minded, intolerant, old-time veterans of the field I used to look down on when I was but a young Whippersnapper. They were so limited in their view, only being able to do what they have always done, always disagreeing with me, always putting roadblocks in my way, always wiping out my carefully crafted abstractions in favor of in-line code, always throwing out my object-oriented design in favor of procedural, always turning my portable, reusable code into use-once code. I never stopped to think that their objections might have been born from decades of experience and life-long expertise.
Now that I’m officially on the other side of the fence, I’ve discovered a new rule: When your junior colleague thinks his fancy object-oriented code is simpler than your straightforward procedural code, you know it’s time to raise your rates. Because they’re not listening to you, so you know you can’t be charging them enough.
The Old Fogey Software Engineers is an exclusive club. Not just anyone is eligible for membership. Yes, there’s the age rule. You have to be pressing middle-age, at least, though the age limit seems to be lower than when I was a mere Whippersnapper. But it’s not really about age, nor about hair color. And it’s not about stubbornness. I’ve known many Whippersnappers, and even some Newbies, who were more stubborn than the Old Fogey Software Engineers. Rather, it’s about changing priorities, and about looking backward instead of forward.
So how do you know if you’re eligible to be an Old Fogey Software Engineer? Well, you know it…
- … when you’d rather deliver new features than play with new technology.
- … when you get pissed every time a Whippersnapper commits new code.
- … when you object to 517 lines of code, because you could do it in 10.
- … when the Whippersnapper who so carefully crafted those 517 lines claims his solution is simpler than yours, because “look at all the neat ways we can extend it!”
- … when he claims, yeah, your solution looks simpler, until we need to do X, Y, and Z. (Even though you have no immediate need to do X, Y, or Z.)
- … when you wonder, what’s the point of writing automated tests after the code already works.
- … when you object to splitting code between two modules, when a single module would serve just as well.
- … when you complain that you can’t find the code that does X, because a Whippersnapper has added too many classes.
- … when you think that inheritance, delegation, and design patterns are overrated.
- … when you object to using more RAM or CPU than you need to.
- … when you long for the days when software was released with no significant bugs.
Sigh.
The saddest thing about software engineering, as it is practiced today, is that it favors Newbies and Whippersnappers. By the time a developer is eligible to be an Old Fogey Software Engineer, he has usually decided to leave the ranks of his fellow developers, maybe become a consultant, or go into management. Or become a novelist.
I’m sure the above is not an exhaustive list. What other signs are there that you might be an Old Fogey Software Engineer?
-TimK
“when you wonder, what’s the point of writing automated tests after the code already works.”
So that new features or refactorings don’t break working code. Our test suite saved my ass earlier today, so this one is fresh in my mind. Also:
“when you long for the days when software was released with no significant bugs.”
Which days were those?
When you tell people in re-architecture status meetings that the schedules are science fiction, and then when the inevitable post-mortem comes up a year later, and they ask why it took a year, and you point out that you said that’s how long it would take to rearchitect the system, and they say, “but we believed the people doing the rearchitecture” and you say that you were the only person that had done a project of equal complexity in the meetings. And they just shrug (as you recall that the response at the time was “if it takes a whole year, it wouldn’t be worth the cost.”)
Hi, David. Yes, tests assure that new changes don’t break working code. (And I’m a huge fan of tests, as you can see from other posts on this blog.) So I add tests before refactoring certain code or adding features that could break it. So yeah, write tests before getting the code to work. But after?
Actually, this is all a little tongue-in-cheek, because I know there are advantages to writing automated tests, even after the code is in place. My snide comments are more a knee-jerk reaction to those (younger) programmers who continually churn out reams of untested code, always claiming they’re going to do the tests next.
Days when software was released with no significant bugs: I remember commonly buying working software for my ZX81, VIC-20, Commodore 64, and so forth. Of course, that software was less complex than what runs on today’s machines. But it was also developed to be bug-free, because as soon as it was deployed, it was expensive and difficult to recall it if a bug needed to be fixed.
Chris, Makes you feel kinda like House, huh? No matter how many times he’s right, Cuddy, Wilson, and his staff still double-guess him.
-TimK
I remember plenty of buggy Commodore 64 software back in the day. I think our expectations are much higher now. Back then if a game had a glitch, you just hit reset and started over.
House is wrong all the time, until the last wild guess which he clings onto, and then is proven right…
Statistically, Cuddy, Wilson, and his staff are right to double-guess him because more of his opinions are wrong than right. 🙂
> So yeah, write tests before getting the code to work. But after?
I think the point is, sometimes you’re in a position where you’re handed a bunch of code with no tests, and you’re asked to add features X, Y, and Z. At that point, some would say, try to add tests for the old code, verify, *then* add tests for your new code, **then** add your new code.
And once you stop worrying about hurting the tender feelings of the Whippersnappers and tell them to just do it your way or just check in fixes to their code without discussing or explaining it (“lines: -517 +10”) because you’ve already explained it and they won’t listen anyway, then you’ve gone past Old Fogey to Grumpy Old Man.
…when you ask “does the system have enough memory? How does your code handle out-of-memory?” and the Whippersnapper says “Memory? What’s memory?” and you say “…you know, when the processor needs to store…” and the Whippersnapper says “Processor? What’s a processor?” and then you strangle the young Whippersnapper and receive a life sentence comfortable in the knowledge that that’s not going to be very long because you’re an Old Fogey.
Martin: Maybe I just didn’t use enough Commodore 64 software. I don’t remember any of it being buggy. If our expectations are higher, though, that’s a good thing, IMO.
steve: Yeah, House makes wrong (though usually correct) guesses. However, he always saves the patient in the end. You would think with that track record, he’d have earned a little respect.
John: Absolutely! That’s what the best engineers I know would do. Frequently, though, I run across new code with no tests, and… Well, that’s the point. Why write tests unless the developer will write them before he writes the code? Otherwise, someone else ends up writing tests to cover that code, in order to add feature X. (As you said.)
Jeff: 😀
Brent: OMG. Did this actually happen to you?! (I mean the part about “What’s memory?” and “What’s a processor?”)
-TimK