Comments on: How simple is too simple?

By: Dan North

Dan North — Sun, 04 Jun 2006 21:06:03 +0000

That’s an interesting observation. Before I got into mocking using jmock, I was also very wary of interfaces everywhere. Especially the dreaded Impl antipattern – the 1-1 mapping of CheeseService to CheeseServiceImpl. I’ve found that using TDD with mocks helps me “discover” services and dependencies that I mock using interfaces, so that I can defer worrying about the implementations until later. Tim Mackinnon – one of the originators of mock objects – describes these interfaces as “flex points”. The interfaces that come out of mock-based TDD seem to appear just where I need multiple implementations down the line. Still not sure how, but I trust the mocking pixies and it seems to work.

By: del.icio.us bookmarks - 2006-06-03

del.icio.us bookmarks - 2006-06-03 — Sun, 04 Jun 2006 07:26:33 +0000

[...] DanNorth.net » How simple is too simple? [...]

By: Simon Baker

Simon Baker — Sat, 03 Jun 2006 10:42:46 +0000

Hi Dan,

Thanks for writing this interesting and thought provoking article. To hopefully put a face to a name, we met at ACCU this year. Syd introduced us. I previously worked with Syd before he joined Thoughtworks. I was at ACCU with Mauro Talevi and sat with him and joe Walnes in the Gumption Traps session.

Simon Baker.

By: Bruce Eckel

Bruce Eckel — Thu, 01 Jun 2006 15:40:21 +0000

“It does not discard using interfaces (almost) everywhere (*)”
Using interfaces everywhere is exactly the kind of “maybe we’ll need this” thinking that DTSTTCPW is intended to eliminate.

By: de tomKronieken » DanNorth.net » How simple is too simple?

de tomKronieken » DanNorth.net » How simple is too simple? — Thu, 01 Jun 2006 15:29:57 +0000

[...] DanNorth.net » How simple is too simple? [...]

By: rebelutionary

rebelutionary — Thu, 01 Jun 2006 01:47:55 +0000

I’ll just do only, first, simplest thing I know that works……

TW Dan has written a very thoughtful post about the concept of simplicity in agile development: Kent Beck advises us to do “the simplest thing that could possibly work”, but this is often mistaken for “the first thing I could……

By: Pascal Bleser

Pascal Bleser — Mon, 29 May 2006 10:34:40 +0000

Well put. Like Erik, I don’t agree either with Kent Beck’s statement in the scope of developing a framework that’s being used by a wide number of projects and teams (definitely a case of API publishing).

Also, more generally, and IMHO, “the simplest thing that could possibly work” does not mean that you shouldn’t put certain abstractions into place right from the start.
It does not discard using interfaces (almost) everywhere (*), for the sake of putting mechanisms in place, upfront, to facilitate refactoring, alternative implementations, and of course easy unit testing (at the very least to be able to easily implement a stub implementation without having to hack with cumbersome mock frameworks)
(*) except for Domain objects, where it’s to be considered bad practice as of overengineering (see Evan’s “Domain Driven Design”, amongst others)

Neither does it discard “design by contract” (well, a light form that applies to Java, i.e. well-defining the contracts of and by interfaces) or “single concern” patterns. Take those seriously, right from the start, even for a simple solution, even for “the simplest thing that could possibly work” because it will make refactoring and/or providing alternative implementations of an interface a lot easier, even in the short run.

Not sure that statement by Kent was such a good idea… a lot of less (experienced|skilled) developers take that literaly (as they do with a lot of ideas from XP).

But it’s definitely an interesting topic to discuss ;)

just my 2c