I have been a big fan of Kent Beck for many years, mostly from all of his work on jUnit and extreme programming. I have two recommendations for you:
- Follow him on Twitter. I cannot tell you how many thought provoking tweets he has
provided me, I’m sure that I get at least one good nugget each day! - Read his personal blog at Three Rivers Institute. It is a really good source of design and development information. Typically, not a quick read, but well worth the investment.
Earlier this month, Kent tweeted about the “Pragmatic Magazine”. I had been to the “Pragmatic Bookshelf” many times in the past, but did not know about their magazine. This turned out to be complete and valuable educational exercise for me.
| Tangent… You can download the “magazine” in multiple formats: PDF, ePub, or mobi. Since I do all of my reading on my cell phone (Motorola Droid), I downloaded the Aldiko ebook reader. Within a couple of minutes, I was able to open up the magazine on my phone, too cool! My poor Kindle is so neglected; I should try to download the mobi format and see how the reading experience compares. I’m sure it will be much nicer on the Kindle DX, but I always have my phone with me, so the Droid wins! |
I was really surprised by the featured articles. I gravitated the to the JSON article; I’m a huge JSON fan, but see it totally ignored in my professional world… I have not figured why this is true, but the article did provide an interesting perspective. One of the other articles that grabbed my attention was on Testing. You have to read it, it is very interesting…
| Quoted from the article… The developers who understand the importance of unit tests and who write comprehensive and subtle tests are exactly the group that need them the least. The “average” or inexperienced developer probably doesn’t believe in unit tests and will write bad or pointless tests if forced to do so. |
So, the question is: Who should write your unit tests? This answer to this question really emphasizes something that I always try to stress to project teams: Do not test your implementation, test the behavior, the contract, you need to support. So many times, especially if testing is not second nature to the developer and the team uses a code coverage tool, there is a very bad tendency to write tests which are specific to the implementation. To make matter’s worse, some teams do in-package testing of their Java code to exercise and validate the implementation details. I was so fired up on this point last year, so I wrote a blog on it! Needless to say, I think this is a really bad idea and creates unnecessary and undesirable coupling between your unit test and implementation.
The author goes on to suggest that your best developers should only create the interfaces and associated unit tests, let the other developers create the implementation behind the interface. Pretty cool idea. Unfortunately, I don’t see this taking off in the corporate world. In my experience, most developers tend to write their own unit tests or unit testing is completely outsourced to some third party (way after the fact). Additionally, the “first tier” developers are expected to write the hard code, and that is what they really want to do anyway; the “second tier” developers usually get the leftovers, like unit test cleanup and shell scripts.
I think the whole value system is skewed in the typical corporate software development process. Where should you put the good people to get the most value? In the past, if you did not cut it as a developer, you would get promoted to the CM or testing team. Many times, these teams were not valued by the organization, and hence not staffed with top talent. I would prefer the best and brightest developers in the testing space. No matter how good the code is, if the testers are sub-par, then the application is destined to fail. Conversely, if you have marginal developers and a strong test team, I think you have at least a chance of success (providing you have a good design).
I read another interesting article about bug tracking and system testing. Think about this… rather than creating a problem ticket for issues found in system test, why not create some type of unit / integration test to demonstrate the problem? The test get checked in by the test team and breaks the continuous integration build process. Now, the development staff just has to fix the problem. Seems kind of streamlined and efficient; I guess it will never work! But I do like the concept!
