Question of the Day

I respectively disagree, and that’s what it’s all about anyway – if there was a silver bullet we’d all use it.

In my mileage myself, and coworkers, we have been burnt by inheriting other people’s service-locater/MVC applications that had hundreds of pieces. Lot of extensibility was built in, but the application was a memory hog, slow, and took forever to debug because everything was abstracted out to the nth degree.

Obviously we all know that there are plenty of applications that this particular design works great – but it’s all in the bell curve, or as an old saying goes, too much salt ruins the pot. I think this is where we disagree; I see flexibility and extensibility as a bell curve with complexity and maintainability, and I get the feeling reading these comments that this is a purely linear formula to some, or it doesn’t drop off until the extreme degree.

History repeats itself. Mark my words, in the next 2 to 5 years these same people who are pointing out the limitations of [language of choice here] will be complaining about the current [language/pattern of hype here] that they’re all on the same wagon about. How many of you remember Microsoft in ~2002 saying ASP.NET was a great example of MVP? Interesting how that’s changed in the last 2 to 5 years.

@Chad:
I’ve yet to have a test written properly (short, concise, focused on one function) get twisted in knots using Typemock. Perhaps that’s because I follow the TDD principals Kent Beck laid out in his TDD book and can also be found in Pragmatic Unit Testing. The only time my tests fail is when I either A) break the code accidently (good test then), B) change functionality or behavior of the method that is being tested – and no testing tool will get you around that.

@Jeremy
RE: I want you, and all the other TypeMock users, to remember one thing, depending on TypeMock to fake dependencies that you new() up directly in your classes is a VERY TIGHT RUNTIME COUPLING. You say that you’re only adding the extensibility that you need, but that statement is false. You’re only adding the extensibility that you THINK you’re going to need in the future.

1. COUPLING != BAD in certain instances, lest I have an interface for ‘string’ or ‘Point’ – and who said I’m newing up anything? I may be using service-locator for all you know. Maybe I’m using Typemock for statics, or protected, or private methods because I don’t want to make things public that have no need to be and want things to be static, to be static.
2. I don’t ‘think’ anything, I illicit requirements, sit in meetings with directors, technologists of other departments, managers, and other people who guide the 3-5 year strategic technology plan of the organization (do you have one?), and we collaborate/brain-storm/etc what level of extensibility, flexability, and scalability is required on a particular project based upon the expected lifetime of the application we’re writing (plus some time because everything lives longer than it was suppose to). I stopped being a cowboy coder and deciding what I thought was needed a very, very, long time ago. I also stopped trying to write applications that would last 10 years, and solving every potential problem that may arise several years ago – otherwise nothing would of gotten done because in 1998 I would of been trying to figure out how to get my classic ASP application to still be valid today (that would’ve been a waste of time and money huh?).

@The Other Steve:

While TDD may be a relatively new PRACTICE, the underlying concepts it helps to enforce and even guarantee are NOT new/hot topics. In fact, I would argue many people have gotten away from the fundamental principles of good design and a lot of these new, shiny frameworks are actually detrimental to your becoming a better software engineer and therefore you should avoid them, or keep them at arms length when using them.

You can learn the fundamentals without TDD, but it sure makes it a lot easier!

@Brian,

Let’s go way too generalized and say that a “good” design is one that maximizes return on investment. Scalability is important in *some* but by no means all systems. In absence of extreme needs for real time performance, scalability, or security, I’d say that the number one quality is maintainability. Testability is simply a (very big) factor in maintainability. Testability is largely a result of separation of concerns, cohesion, and loose coupling between different responsibilities in the system. The same qualities that lead to testability lead to making the system easier to understand and easier to modify over time.

“‘ve also created more moving parts (or allowed the creation of), and I think common sense will tell us that the more moving parts we have (or can have), the more complex the system, and logically the more complex the system, the harder to maintain”

Maybe, but I think that thinking is largely a myth. Given the choice between 100 cohesive classes with well defined responsibilities and 10 big classes that do lots of things, give me the 100 pieces. The only way to deal with real complexity is a divide and conquer strategy that allows you to do one thing at a time. Arguably, you could say that a good design structure is one that allows you to work with and understand one part of the system at a time. How often are you really changing an entire system? Most of the time changes *should* be isolated to one aspect of the system.

I want you, and all the other TypeMock users, to remember one thing, depending on TypeMock to fake dependencies that you new() up directly in your classes is a VERY TIGHT RUNTIME COUPLING. You say that you’re only adding the extensibility that you need, but that statement is false. You’re only adding the extensibility that you THINK you’re going to need in the future.

@Roy,

I have no problem with TypeMock existing, I just don’t feel like its abilities are that important in the greater scheme of things. If you’ll actually bother to read what I’ve written about TypeMock you’ll see that I’m directly criticizing the rhetoric from you and Eli and the gang. I think you are all confusing “it’s technically possible to write a test for this code” with “this design is good”

Besides, depending on your product for mocking instead of using DI still leaves you with tightly coupled code and eliminates possibilities for reuse and evolutionary design. Using TypeMock is a compromise.

My point of view on TypeMock (that you and your cohorts either won’t admit or refuse to recognize) is that it will not help you all that much with bad designs.

“moving to a less friction language will achieve the same conditions that, by your theory, will produce the same bad design you fear.”

I don’t think that makes the slightest bit of sense if you think about it. Take Ruby for example, all the mockability and *swappability* that I get with DI in C# comes for free in Ruby. C# + TypeMock isn’t as good of an answer in this regard as Ruby.

Plus there are other advantages you’re not accounting for. Simply switching to an interpreted language makes the TDD cycle much, much faster. And remember that Ruby is much more terse than C#.

On the F# side, doing purely functional programming means that you wouldn’t have to bother setting up any mock objects at all.

So, what is C# was testable by default? like Ruby?
That would remove the friction, right?
So if a product such as (you know) helps achieve that, why in the world do you still have a problem with it existing, claiming that it will ruin good design guidelines?
moving to a less friction language will achieve the same conditions that, by your theory, will produce the same bad design you fear.

While I do not see a big problem with writing testable code in C# I would definitely try to switch to F#. C# is good if you think about testing from the beginning and you will likely be able to test what you need without any special frameworks for mocking etc. Homegrown set of utilities and nunit will likely be sufficcient. So, just think about testing when you design the system.
However, F# gives us some very useful things like “computation expressions” which allow wrapping code (add special handling) for testing purposes like ensure invariants on each step or simulating real user behavior.

“a feeling by Chad & I that it was a low risk choice”

How very courageous of you both.

I had the same thought at one point. http://kevin-berridge.blogspot.com/2008/07/static-languages-dont-trust-you.html

But like you say, there’s a cost and risk in switching. Not to mention that in the corporate world, it’s not a private decision, you have to switch everyone.

But I think that static languages do hinder TDD adoption. Mainly because it requires using the language in a way that is non obvious.