Comments on: You Know You’re an Old Fogey Software Engineer When…

By: J. Timothy King

J. Timothy King — Fri, 24 Aug 2007 05:50:58 +0000

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

By: Brent Noorda

Brent Noorda — Thu, 23 Aug 2007 21:50:09 +0000

…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.

By: Jeff

Jeff — Thu, 23 Aug 2007 19:52:01 +0000

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.

By: John

John — Thu, 23 Aug 2007 17:19:33 +0000

> 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.

By: steve

steve — Thu, 23 Aug 2007 16:29:42 +0000

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.

By: Martin

Martin — Thu, 23 Aug 2007 15:30:43 +0000

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.

By: J. Timothy King

J. Timothy King — Thu, 23 Aug 2007 15:10:05 +0000

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

By: Chris Austin-Lane

Chris Austin-Lane — Thu, 23 Aug 2007 02:12:33 +0000

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.”)

By: David

David — Thu, 23 Aug 2007 01:11:24 +0000

“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?