Something strange is going through TDD land these last couple of weeks. First it was Uncle Bob,with a new TDD theory – making tests pass in a certain order, actually helps incremental design, leading to a better solution. This is a very interesting post, and if he’s right, he might have discovered the cornerstone of
After the LIDNUG presentation, we stayed online to discuss unit testing experiences. A couple of things stayed with me from that talk. One: we’re (we developers) are obsessed with tooling and technology (you didn’t expect hard news here, right?). Our main focus should be about solving the business problem first. But, us geeks, we like
I try not to miss them, but the last .Net user group was about refactoring. I’ve been refactoring before I wrote unit tests, which was very courageous (and stupid). This post is a response to Gadi Meir’s post (in Hebrew) in which he states that refactoring policy should be defined by the CTO or equivalent.
This is something that I used to hear from the developers. I bet I used it as a developer and then I got a change to use this phrase today. I have a small task scheduled to run on a server to collect bug information. It ran every day at 3am, until a month ago.
We’re working on collecting metrics for the upcoming Management Review, and I’m currently collecting bug information of the different project releases. The data is exported from the database to Excel, and there I do most of the math. At some point, I was sure I was making mistakes, because the formulas became complicated, and if
The managed run time for dynamic languages looks cool. I’ve been reading on Ruby lately and the simplicity can take you a long way. However, this could be a curse too. I remember I was in TechEd Europe a few years back, and went to a talk regarding Lotus Notes and Exchange integration. Yes, it