Helltime for April 17
Yes, this is another retro-active Helltime. My excuses are 1) the second book of the new novelization of Doom 3, Maelstrom by Matthew Costello (of which I read 150 pages last night), and 2) the Padres are in town playing the Phillies, and they don’t look like the team that lost 99 games last year. I’m sure you understand.
Announcer: Now for quick hits and commentary on software development topics from around the web, the EIP web-ring brings you the stigmatized spawn of a refactory, MoffDub, and Helltime!
- Question posted on proggit: What careers does a software engineer move on to?
Seems to me that if you are asking this question, you shouldn’t be in this business. I can’t imagine moving on to another career. It’s one thing to only write code at work and not as a hobby. If I had a billion dollars and could retire tomorrow, I’d still be writing code all day because it is what I like to do. I think it is another matter if you are already thinking about a post-programming career.
- Testing savant Michael Feathers has a cool post where he writes about something that has bugged me since I started my job last July: what is the difference between different types of tests?
The thing which makes testing nomenclature worse is that the tests themselves aren’t all that different, or at least, they are often not different enough for us to for us to distinguish them without being told. Yes, we can tell the difference between a unit test and an acceptance test in most systems, but really there is no force which prevents tests of different types from bleeding through into each other.
Right on, right on, right on! At work, we have at least four different types of testing: unit testing, integration testing, system testing, and customer acceptance testing. The only real distinction I’ve seen is between unit testing and the rest of the test types.
I also write and execute the integration tests, and I have to tell you, the types of tests seem identical to system and customer acceptance tests. I’m told that the tests use different data and have different focuses, but like Michael points out, I had to be told. And I’m pretty sure I have a draft post filed away somewhere about this topic.
- Misko Hevery also hits on a work-related nerve of mine, stating that “there is a myth out there that creating objects is expensive.” This myth is such a fact at work that “object design”, if you can call it that, is heavily driven by the result sets of a stored procedure, the needs of a UI page, or caching opportunities. This, in turn, is due to the performance demands we place on multiple JVMs running on multiple servers.
I’m sorry. If you have such strenuous demands for memory and resources in your production run-time environment, then maybe you’re doing it wrong. Maybe you shouldn’t use a language like Java if the programmer productivity benefit from the higher level of abstraction is going to be offset by C-like edicts on objects, or lack thereof.
If they’re going to make us write procedural Java, why not take away the performance hit by moving to C?
|Announcer: You’re reading the EIP web-ring.|