Skip to main content

New communication modalities

E-Mail, IM and other stuff is nice to get reached, but unfortunately, it's also very time-consuming. Especially if E-Mail is (ab)used as a near-realtime communication system. In order to make it a bit more efficient, I'm changing my communication patterns a bit. I'll try to check mails in a "best-effort" manner in the future, so no guarantees, and the timing is going to be like this. From Monday to Friday, I'll try to check early in the morning (around 8-10) and once in the afternoon-early evening (15-18). IM presence will be reduced mostly to weekends and occasionally in the evening.

If there is something urgent, feel free to call me, or make an appointment. This is going to be much more effective than IM and E-Mail troubleshooting. For E-Mail, I actually analysed all my mail in the last year for "urgency". There is not a single one which would have required a <24 hour response time, and most of the time <48 would have been sufficient. As I'm much faster during batch-processing mail, I've opted in for this new policy -- which in turn should improve the answer quality :), so it's a win-win.

You shouldn't expect an answer at all on weekends, even though I'll try to check mail. I'm also no friend of exceptions, so if there is a deadline on Sunday -- bad luck. The latter worked out very nicely so far, we managed for instance to have a paper finished several days in advance of the deadline, it's all a matter of planning.

Posting on hold

My backlog is completely empty, and I also don't have time right now to flesh out a few of the posts I have in the to-write-list ... which means I'll have to take a (hopefully) short break from blogging. I'll try to write about current events, and I'm also reading/answering comments as they come in -- I'm just going to skip a few Mondays until I have a small backlog again.

Beta testing time

Visual Studio 2010 Beta 2 has been released recently, and CMake 2.8 is also in RC mode right now. In case you haven't done yet, this is the time to give it a try, as Microsoft and Kitware are really into fixing bugs. For instance, nearly all of the bugs I reported in Beta 1 of VS 2010 have been fixed in Beta 2 (on the other hand, a whole crop of new bugs appeared in Beta 2 ;) ) Anyway, if you'll have to use VS 2010 in the future (I will have to as DirectX only works on Windows), you should really take some time and test your stuff now and report problems, otherwise you'll end up cursing for the next few years.

For CMake, it's not that critical, as the release cycle is much shorter, but if you want good support for VS 2010, you should start testing now. My personal project here does not work quite with CMake and VS 2010, but Kitware is very helpful and we're trying to iron out the last remaining issues.

In my opinion, far too many developers just blame the tools, and never ever report bugs actually. Sure, you can hope that your particular problem gets caught by the QA one day, but reporting really increases the chances. After all, you want your clients to properly report bugs as well instead of spreading bad publicity, don't you?

Note: I'm not working for Microsoft or Kitware -- I just picked those two, as they have products in the making which are likely to impact a lot of developers.

Postmortem: Diploma Thesis, 2

Welcome to the second part of the post-mortem analysis. In the first part, I mentioned the things that went right, now it's the time to find out what could have been better:

  • Direct usage of std::iostreams everywhere: Well, the main problem here is that I thought that an iostream will throw an exception if used incorrectly (as I was used to from .NET and my own projects), but this is of course not true -- an iostream will just set the fail bit, and you have to check for that. Unfortunately, this became only a problem really late when certain files were missing and things would break silently. For the future, I'll wrap the iostream creation in a function which throws an error if the file is missing.
  • File I/O part two, even though I had text files, I missed two key points: Versioning and type-information. That is, each file should have a header like "Scene 4" or so, which is checked by the corresponding reader. Again, this wasn't a problem during development as I used to pass the right files everywhere.
  • You probably see a pattern already, but there were a few more instances of "silent" failures -- I'll have to take special care next time to avoid all possibilities of loading wrong data or partial data. I'm also thinking about adding checksums to each file, even though it makes quick manual editing a bit more complicated.
  • Manual threading: All threading should have used OpenMP from the beginning, which would have saved quite some time. Notice that with OpenMP, static scheduling can lead to bad behaviour if the individual items take vastly different amounts of time, make sure to profile the CPU usage. I had to use dynamic scheduling to get maximum efficiency.
  • Unit-testing: I started too late, and added all in all too few unit-tests, which led to some hard-to-track down bugs.
  • Functional testing: I had no functional testing in place. In retrospective, there is a really easy solution to this: Add a script layer (for instance, using Lua) to issue all commands to the app and also to query the state. This allows easy recording of all UI actions and replaying them, and makes it extremely simple to automate testing. Another huge advantage is that an "undo" system comes for free, as one can replay everything until the last command. Definitely something I'll try next time.

So much for the down-sides, doesn't look to bad after all. I guess I'll read through the code once again in a month or so, but so far, I'm halfway pleased with the results. Especially as the code was under constant change most of the time :)