[LRUG] Dependency Injection and DHH

[Tim Cowlishaw]

On 28 April 2014 15:25, Paul Robinson <paul at iconoplex.co.uk> wrote:

> Working alone and intend to do so for ever? Why bother documenting behaviour
> through tests when comments have done you fine so far?
>
> Increasingly complex code base where it's hard to understand interactions?
> Use a functional programming style and the complexity might just slip away.
>
> Want to refactor for performance but scared functionality will break? Manual
> testing and QA might be fine if you've split everything out into smaller
> modules.
>
> Now of course all of those counter-argument can be defeated with specific
> examples. So in that sense, I think you're right that talking about why we
> do things the way we do them rather than looking at specific tools might be
> of benefit.
>
> But we must also understand that there is no "right" way, only the way that
> works best with the problem domain, team and resources you have to hand.
>

There's tons of wise advice on this thread already, but I think this
in particular is a really important point, especially for the
contractors among us. polemics like DHH's (and there exist pro-BDD
arguments with a similar fervour too) encourage us to think of this as
a big clash-of-cultures style debate between two ideologies, while the
reality, I suspect is far more useful (but less interesting if you
like big online arguments), and it's something like this: There exist
strategies for reducing complexity in your programs and for verifying
their behaviour, a subset of which complement each other very well and
which are known collectively as BDD, GOOS or Object-oriented-design).
They are extremely useful, but *don't* have to be taken all together
to be useful.

When working with clients, I try to follow the picnic-site rule of
leaving the place in a better state than I found it (better factored,
better test coverage, with added functionality, and crucially, more
understandable). This has always involved using BDD and
object-oriented design techniques, and often, coaching clients on the
benefits. However, a key part of this is demonstrating the way in
which using these techniques can lead to immediate, significant,
INCREMENTAL gains in producticvity and confidence. Letting the best be
the enemy of the good by being too prescriptive about these techniques
is in no-one's interests. Simply, if I took a client's money with the
expectation of adding value in the short-to-medium term and completely
rewrite an existing system in a good GOOS-like style, they'd be left
with a codebase that (while certainly less brittle and easier to
extend) could be almost entirely unrecognisable to those who've been
working on them for years (and will do so in the future), and I won't
be asked back.

Similarly, if I'm asked to quickly prototype an idea, or do some
exploratory work on an existing dataset, with the knowledge that the
code I wrote almost certainly won't make it into production, but that
the insight derived from the process will inform the client in the
future, the costs of working in a strict BDD style almost certainly
outweigh the benefits.

However, If I'm working on a relatively young codebase, that'll need
to be maintained and extended well into the future, or developing new
features for an existing codebase, I'll work very hard to convince
anyone involved to work to the BDD cycle, as it's here that it
delivers the most value for the least effort.

BDD and object-oriented design are two of the most useful tools in the
good software engineer's toolbox (if not the most useful ones - Tom S
makes a better argument for this than I could do, above, so I won't
repeat it). However, the cost-benefit trade-off is cruicial, and is
highly context-dependent.

Cheers,

Tim