Jerome's Blog

I've been following the #isTDDDead debate, and I've heard feedback loops brought up often. Part of the benefit of TDD is that you get quick feedback on your designs as you go, and you know immediately if you've violated any previous assumptions. Feedback loops are also core of The Lean Startup by Eric Ries, in particular the Build, Measure, Learn feedback loop. Feedback loops are just limited to software development. For example, do you ever think about how much you need to turn the steering wheel? There is no way to teach someone this ability - they need the feedback of the cars movement to know for sure. I don't remember hearing much about feedback loops during my undergrad years (1995-2000). It was around that time that Kent Beck et. al. were publishing JUnit, TDD, and XP. It wasn't until years later that I heard about these topics. Even then, I don't recall hearing about feedback loops as much as I do today. For me, one the main benefits of Agile m

The last couple of code reviews of my work lately have turned up some common code smells: function names that don't adequately reflect behavior; misplaced functions; and sub-par function decomposition. I don't think I'm the only developer afflicted with the bad naming, since it's one of the two hardest things in computer science. However, the function placement and improper decomposition are a signal to me that I have a clarity problem.  I've been building software for almost 12 years, and I take my coding very seriously. I'm pretty sure I have OCD tendencies, especially when it comes to code. Ever have to shut off your car when you realize that the emblem on your key is facing the wrong way? I have :).  My desk is littered with programming books like Pragmatic Programming, The Practice of Programming, Clean Code, Refactoring, and Domain Driven Design. But despite my years of development and many programming books I've read, I still find softwar

The recent debate over #IsTDDDead is very interesting to me. Not because I believe TDD to actually be dead, but because I think it goes against core beliefs of some software developers, especially for those who practice TDD on a regular basis and has now become integral to how they build software. Now that the shock of the proclamation that TDD is dead has subsided a little bit, we can start examining the reasons prompting this statement, and maybe incorporate some of these thoughts back into our own views of software development. But for that to happen, we need to reflect on our own view of the world, and be open to the possibility that some of our views might be wrong. Admitting that we're wrong is something that can be hard to do, especially if its our long standing beliefs that are in question. Strong opinions, weakly held I approach software development assuming that there is a better way, but I haven't found it yet. As a result, I'm always in pursuit