Quasi-Editorial corrections of DIRTI by @ircmaxell

IRCMaxell, a fellow PHP developer and Freenode user, wrote an article on his blog, entitled Beyond Clean Code.

For me, the good point in this article is about re-thinking how much investment to make into trying to make better code, which I think is very important for a software developer to learn, so that they are able to create the highest ROI possible for their employer. No question this is an important lesson that we all need to be reminded of often. As often as every week, really.

I’ve had the opportunity to talk to IRCMaxell on ##php on Freenode IRC before. I think that he is a cool guy, with interesting depth of experience and laudable focuses on security and writing code that delivers business value. Here’re some corrections I would make to the article:

• Dirty and Clean code are not absolutes. In my experience, some code can produce low business value specifically because it is poorly written, even if it addresses a problem that would have otherwise brought good business value. Of course, any code that manages to avoid failing to deliver the business value because of how badly it is written, is by definition good enough. At the same time, perhaps there is opportunity to maximize ROI by investing into teaching the developers how to produce better code in the future, through minimizing technical debt.
• He understands and defines TDD as “understand the code you’re trying to write before you write it”, which is not actually TDD from what I understand based on the clarifications in places like TDD as if you meant it . In that article Keith Braithwaite calls the approach IRCMaxell describes as “Pseudo-TDD”. It seems to me that DIRTI is basically TDD, except with unit tests after the code. I would venture a guess at the choice for doing it after the code because he does not really get unit testing. I am also not very good at unit testing, and it seems extremely hard to get good at, and there is a lot of misguiding material out there, and not a lot of good material.
• He calls TDD and Pair Programming “Methodologies”. They simply are not methodologies, because they are tools, or rather practices. An example of a “Methodology” that incorporates ( and birthed ) those two practices is eXtreme Programming.