Thoughts on Web Development
I mentioned in my previous post that I believed much of the backlash against TDD is more technical in nature than many in the .NET developer community have realized. This post is to expand on that thought a bit further.
Many of the issues that .NET Developers have around doing TDD in C# is the requirement of using a large number of Interfaces around dependencies to make classes more testable. Writing your code this way requires practice, discipline, and most importantly, the appropriate tools.
I’ve long since reached the conclusion that the out of the box developer tools provided by Microsoft are wholly inadequate to using a Test First methodology. MSTest has always been a weaker alternative than NUnit, despite having nearly 5 years to catch up. Visual Studio still does not provide enough refactoring support, code navigation, or targeted code generation without an add-in like Resharper or CodeRush. Truly understanding TDD requires a mastery of these tools and others like Rhino Mocks and StructureMap.
Recently I’ve taken it upon myself to relearn Ruby on Rails after a long hiatus. Juxtaposing the Ruby ecosystem against the .NET ecosystem has been eye opening. For one thing, as a dynamic language, many of the technical barriers of doing TDD don’t exist in Ruby. Mocking and Dependency Injection have little to no value in Ruby as neither one is required to unit test your code. On the flip side, common compile time errors in a static language like C# can become runtime errors in a dynamic language like Ruby. The frequency and potential for these kinds of errors makes unit testing no longer optional when coding in Ruby.
Also, the Ruby community uses surprisingly few developer tools. Most Ruby developers use the most basic of text editors like VIM and TextMate to write their code. They do use a lot of libraries (or gems as they call them), but most of these are free and open source. Not having a corporate leader like Sun or Microsoft has forced the community to be far more self sufficient and create their own ecosystem. It is also evident that all of the thought leaders have also made significant open source contributions.
The .NET community has made strides in the same direction, as many of the new leaders at Microsoft like Phil Haack and Scott Hanselman came from the developer community and have made significant open source contributions. However, I believe the core technical issues that surround a statically typed language will only continue to hurt the platform’s growth. Ruby and Python will only continue to make gains in performance and productivity. Eventually Microsoft will have to respond with a suitable dynamic language. This may be coming sooner than expected based on John Lam’s departure from IronRuby to form a new team that is working on a new secret project.
It seems as though the .NET developer community is becoming more polarized regarding their thoughts on the value of Unit Testing. I see it as a split between those that are dogmatic about Unit Testing, and those that are in denial that it has any long term value.
Some of this was spurred on by Cashto’s “It’s OK Not to Write Unit Tests” post, but I think that sentiment has been brewing for quite some time and it just hadn’t properly been put into words.
I think Cashto had some valid points and that in certain instances, Unit testing and TDD can become cumbersome. In my opinion, the following would need to be true to get away with not Unit Testing.
While some may consider these three conditions to be unrealistic, there are certain small lean startups or small consulting projects that can operate under these assumptions.
The problem with the .NET community’s reaction to cashto’s post was that the dogmatic individuals immediately dismissed it and the ones in denial unconditionally embraced it. The dogmatic strictly believe in a test first methodology, and are quick to dismiss any notion of the contrary. The irony is that their dogmatic attitude is reactionary to the “no testing” attitude previously espoused by many in the community, especially those most closely associated with Microsoft. Those individuals who fully embraced cashto’s post and cried “Unit Testing is Dead” are the ones most often in denial that never really gave it a chance. These individuals may have dipped their toes into Unit Testing years ago and quickly gave up without putting enough initial effort or seeing any results.
For those of us who fall in the middle, the path has become unclear. The dogmatic approach can be off putting, especially when faced with the often harsh attitudes of those espousing it. Staying in denial, however, is not an option for those who have been in the trenches and seen more than a few nasty bugs caught with good unit tests.
I have chosen to look outside the .NET community and see how the Rails community has dealt with this issue. I suspect that many of the disagreements are actually more technical in nature than most people realize. More on this in a future post.
Software can often be a challenging product to sell. If you don’t have a great sales team, it can be difficult for anyone to know just how good your software is.
Many great companies with fantastic software have fallen flat due to a lack of sales revenue that resulted in them being eclipsed by a poorer quality competitor. This phenomenon has prompted many software companies to fore go quality in return for beating their competitors to market. The idea being that even if your product is of poor quality, your customer base may be locked in long enough to give you time to actually meet their needs. Twitter is a perfect example of this.
While I think there is some validity to this thinking, too much of it can lead to a very bad pattern that I’ve seen in nearly every software company that I’ve worked in. It goes something like this:
The main problem here is that there is zero accountability for the Sales team’s actions. Usually, Sales is a separate and independent department that is measured on their pipeline, not on long term relationships with customers. Upper management is often reluctant to restructure organizations, as it might result in lost sales. Also, because of the way sales commissions are distributed, a net operating loss from a customer never affects Sales teams’ compensation.
As a developer on the other side of the fence, it is easy to point the blame at the Sales teams for their irresponsible behavior. However, it should be upper management’s responsibility to build in accountability for customer relationships with sales teams so that this type of situation does not repeat itself. While Sales are a very important part of any business, left unchecked they can wreak havoc on the long term viability and reputation of your organization.
The Web Gambit 