Opinion

I have been working on a somewhat legacy codebase which makes use of the Servicelocator pattern. Although I always thought of Dependecy Injection to be the superior pattern, I was pleased to find some Inversion of Control implementation in there. Working with the codebase, I discovered first hand how easily, when used without caution and discipline, the Servicelocator pattern can introduce code rot. I will walk you through some of the issues I have with the Servicelocator pattern, mostly looking at it from a test perspective. It’s interesting how you can often quickly discover friction in a codebase by just looking at, or writing, tests. ...

I have had a fair amount of discussions on continuous learning and knowledge sharing the past few days. It became rather obvious that a lot of us have developed their own techniques, but also that maybe most of us are still in search of more efficient techniques. Having gone through several phases myself, I would like to share my current way of learning: the Hacker Way. Here are some snippets taken from a recent letter from Mark Zuckerberg addressed to the Facebook shareholders. ...

In this post I would like to share some of my thoughts on a recent post by James Hague titled ‘Don’t Fall in Love With Your Technology’. If you haven’t read that post yet, please do, it’s so short that me summarizing it here would be silly. I think there is nothing wrong with falling in love with your technology per se. If you want to have a fair relationship with your technology, you have to invest in her. Don’t have a superficial relationship, take her home with you, spend some cosy Sunday afternoons together. Get to know her inside out. Know when it’s fun to be with her, but also more importantly when it’s not. ...

Before publishing my previous post on rewriting an if, I knew some people would hate it, because the refactored construct is less performant. Although I think performance is important, relevant performance improvements are, apart from in tight loops, hardly ever to find in language constructs. To put it more bluntly, they are a waste of time. When translating your thoughts into code, you should aim to make your intentions as clear as possible for the person who comes after you. Don’t obfuscate your code for an negligible performance improvement. ...

Blame no one but yourself. This is one of the few quotes I remember months after reading this book. Although it’s a harsh statement, there definitely is some truth to it. Once I started observing my own behavior when faced with failure, I caught myself regularly blaming others for failures to which I am - at least - an accomplice. Think about it. You might be guilty of this too. Frustrated with management because you missed their too tight deadline? Did you tell your project manager that taking that ‘one small’ task in between would get you behind on schedule? Dissapointed by your team mate because he messed up the task you asked him to do? Are you sure you gave him all the information and provided enough feedback? Tired of doing the same repetitive task over and over? Why haven’t you automated it yet? Not happy with a certain implementation? Did you speak up and propose alternative solutions? ...

I recently blogged about programming for the future of mobile with jQuery Mobile and the WebAPI. You probably heard that jQuery Mobile 1.0 was released earlier this week. Although it will take a while before we will see some actual results from the WebAPI initiative, that shouldn’t keep us from letting our minds play with things that might be possible one day using the WebAPI. The thoughts in this post were provoked by an interesting comment Kristof Claes left on my previous post. ...

Just after graduating, I hated legacy with the heat of a thousand suns. I felt unfortunate, having to work on old code, built using outdated technologies, while software is all about making new and shiny things. Right, guys? Those naïve expectations of a rookie got crumbled very soon. Legacy is a constant in our industry. You can try to ignore it as long as possible, but it’s impossible to keep that up forever. Over the years, I have come to accept that. I even have been fully embracing it lately. ...

Something that can bother me tremendously is being surrounded by people who are in a constant state of being comfortably numb. People who don’t welcome change, try to scare away new concepts and are just too much at home in their comfort zone. Some are perfectly happy filling their days keeping up appearances of being busy. They don’t care about self-improvement, but only care about augmenting their paychecks by accumulating as much legacy baggage as possible, with the sole intention of being perceived as an irreplaceable asset to the company, whilst not having to leave their comfort zone. These people also have the tendency to shy away from responsibility and commitment. They are satisfied with doing just enough to not draw any attention to themselves. ...

Due to the nature of things we build in our day to day job, writing software can wear out even the most fit of us. Most software jobs make you constantly deal with complexity. The amount of things which can lead to a complex software project are immense. A poor first design, and failure to redesign. External dependencies, which seem to behave different every time around. Or just the complexity of the problems itself. You are almost always working in a team, which can be exhausting as well. If the team doesn’t share your passion and you have a hard time getting your ideas across, you will get frustrated, real soon. Add some coroporate politics to the mix and you’ll be on your way to Paranoia. ...

Last week, I resigned from my job at Ferranti Computer Systems. Three years ago, days after receiving my Graduate Diploma in Applied Computer Science, I had my first real-world working experience at Ferranti Computer Systems. The first project I was assigned to, was a project for the Antwerp fire department. Along with two other graduates and four seniors, I was thrown in at the deep end. I always had solid grades in school, and was fairly confident that I grasped the material I was taught. Was I misguided (!): it only took me a few days to realize that I knew nothing about building software. It immediately became clear that I had to start learning and probably would need to keep at it forever, if I ever wanted to get remotely good at this. ...