Daniel Hoelbling-Inzko talks about programming

Feeling like Bruce Wayne


Although I don’t dress up with a fancy black suit and hunt criminals by night, holiday season means living a double life for me.
Most of my friends study in Vienna or Graz and only visit during holidays, so whenever they are all in town I have to maintain a student life during the night while still working during the day. That usually means getting up at 9am while staying up till 5am.

Believe me, when 6 people don’t accept no for an answer and want to play poker at your place, you’d better restock on coffee and make sure you eat light so you don’t ruin your stomach completely. (I start regretting having built my own poker table)

And still, it’s holidays so trying to maintain a 8 hour per day pace is almost impossible. Besides your family obligations at various christmas celebrations and the usual shopping madness there isn’t really enough space to get focussed on something long enough to actually finish it in a good way.

So today I came back to office and started filling out the holes in my application I left during the holidays. Working my way from //TODO: statement to the next, revisiting the old code I noticed one thing: Code quality doesn’t matter.

When I write code I can’t forget it afterwards. I mean, I suck at remembering syntax or class names (man I love google for bringing back my memories over and over again), but if I feel like a solution isn’t elegant enough or a module should be restructured to make more sense I’ll think about it whenever not occupied and eventually come up with something better.
What would have taken me hours to get right the first time, was fixed in a matter of minutes after I had time to think about it. So this leads to the interesting conclusion that nothing I’ll write today will actually matter next week, as long as I constantly rethink and rework my code I’ll end up with high-quality code no matter how bad it was when I first wrote it.

So the most important thing to consider when writing code the first time is not let implementation details “leak” out to other parts of your system, so reworking one part of the system won’t affect the other. Also writing tests for one-line methods may seem dumb and repetitive, but once you start juggling around stuff while a release date is coming at you at alarming speed, those one-line tests will assure that your app won’t blow up once deployed.

Practices you don’t throw away when your deadline approaches

(image by deVos)

So, I’m a bit under pressure right now. I don’t blog too much because I’m bound to a immutable release date of 7th of January. If I don’t get the software out until 7th of January the customer will have to wait for another year before he can make the switch from his (pain in the ass) 15 year old MS-DOS software.

So you see I’m not only a little bit stressed, I’m looking forward to a Christmas holiday I’ll probably spend locked into some room finishing the software day and night.
As that deadline approaches, there are some things I have noticed in my current development that suddenly don’t seem fit any more due to time constraints.

I know my business layer needs a major refactoring (a day or so) to keep my domain logic “clean” of clutter. But I know I can’t spend a day refactoring something that has to ship next week (I want to have the app user tested by 7th). Still I can think before I code.
One thing I see in legacy code all the time is how people stop thinking once they approach deadlines, but start to just mindlessly copy/paste stuff to make it work somehow.

Here’s one principle you should NEVER forget:

DRY – don’t repeat yourself

Not repeating yourself through simple copy and paste will at least make it easy for you not to have to rewrite the whole thing once a change has to be made. I can retrofit extensive tests and good SoC, but I am doomed once I have to change the same piece of code throughout the whole application.

If I’m so stressed that I have to write crappy code, It’s still my duty to fix it sometime later, and that’s not possible if  one business rule (it may be as simple as amount/numberOfRates) is done at 20 different places!
That then leads me to the next point, fixing stuff later requires at least some automated tests (nothing is worse than writing fixes that have more bugs in them).

Testing isn’t difficult, and it saves you more time than it takes. You may think you’re faster if you run the app once and see if it works, but apps don’t run as fast as unit tests, and once you have to run it several times to make it work you would have saved time by writing a unit test first. And although my tests look ugly and may be incomplete, I have verified that the most important calculations and interactions work (and can rerun those tests and verify that stuff still works later when I try to clean up the mess).

So, by applying (even incomplete) testing to my app, and not violating DRY I still retain the ability to easily extend and manipulate my application in the future. Once I’m done I can easily run NCover and find out what code I didn’t cover in my tests..

My Photography business


dynamic css for .NET