Wizards of Smart

Microsoft Research recently published the article “Exploding Software Engineering Myths,” by Janie Chang. For those who haven’t seen it, you will likely be surprised by some of the findings. Chang and his team worked with IBM and found that code coverage isn’t a terribly excellent metric, TDD may not necessarily speed development, Asserts (and by extension Code Contracts) greatly improve development code quality, and organization structure does matter though geographic proximity does not. The article includes links to the team’s published findings if you want more information.

I don’t really think the first finding is all that shocking, but I was surprised by the second. I’ve found TDD as useful as using Asserts–another unsurprising finding, at least to me. The authors do acknowledge that teams using TDD generally face far less post-production issues. So at worst, TDD likely keeps development time the same but allows the development team to catch the majority of the bugs as opposed to the end users. For my money, I would prefer my development team find the bugs and let the end users think we did an excellent job. In addition, you can never know when some bit of functionality just hasn’t been tested by an end user that might require a significant re-write to fix (heaven forbid).

That’s my two cents. What are your thoughts? Are you surprised at the findings?

I have read a lot about YAGNI lately, especially regarding TDD. The thing that keeps bugging me is the definition of “simple.” Who defines simple? For instance, wouldn’t static methods be simpler than building objects? You could then write more functionally. Or is that not simpler to you? If you follow command-query separation, wouldn’t building everything as either pure functions or commands be simplest? JB and I have found this set of patterns immensely easy to create and test of late, especially in comparison to the ever-increasing-in-complexity procedural/OO code in place before.

So I guess my question is this: Is it really so bad to start with some basic patterns that will let you refactor more easily? I think the desire to make things as simple as possible–especially when you know you will need it–can be a waste of time and a good way of getting bad code into your source.

I know I will hear it from the Agile community that I just don’t get it, but I think I do. I really like starting simple and keeping things in nice, bite-sized testable chunks. And yes, I’m still learning. However, without a consistent and meaningful definition of “simple,” we’re likely to end up with a follow-up movement of making things complex for the sake of extensibility again.

So what do you think: is CQS too complex a starting point, or is it a nice, “simple,” and testable approach for YAGNI?