This version of Vestibule is read only. It represents an archive of the community effort to produce content for Ruby Manor 4.


updated about 4 years ago; latest suggestion about 4 years ago

This proposal has been withdrawn...

Machines work only when they break down, and by continually breaking down. — Deleuze & Guattari

Businesses are run in very illogical ways. — Fowler

In my proposed talk, I want to philosophise on and hear what others have to say on complexity. The word, to me at least, signifies scale, overgrown code, error-prone APIs, uncertain business environments, red tape, lack of cohesive business practice to mention a few things.

I'll start with an anecdote: a zombie app[1] that I first built several years ago and have spent the last two years rewriting, refactoring, breaking up, and so on.

I'll throw in some bad strategies you might not want to consider using, like the complete rewrite that is meant to culminate in a migration of everything and fix all evil.

I'll mention frustration: Not knowing where to start, the seeming impossibility of retrofitting tests into the I-somehow-do-it-all code base.

I'll dwell on what we could perhaps say are intermediate strategies of corralling complex responsibilities in abstract collaborations (yes, I'm winking at the flurry of discussion about two months ago around service objects and so on).

Then, I'll move on to my personal favourite: the surgical task of breaking up something that you thought was one thing (an app, a business, possibly both) into many, increasingly independent pieces.

I'll probably end by preaching micro services and say something controversial like "I prefer metrics over tests when the app is only 200 lines of code" to start a conversation.

[1]: Let's define that as something that makes money but that you feel an increasing urge to walk away from.


  • 3f8fcabf5960ae755f6e5479e38939c9 Dave suggests about 4 years ago

    Being hip (or maybe neck) deep in a massively complex and monolithic app build at the moment, I'd be quite interested in someone else's perspectives.

    Especially interested in the "breaking up" part as an alternative to the monolith approach, at least thats what I assume you mean.

    As we haven't even finished round one dev and are already throwing the word 'rewrite' around, it would be good to hear what alternatives others have tried and maybe found more success with.

  • The proposal author responds about 4 years ago

    I suppose I want to talk about complexity in particular rather than testing per se so have edited my proposal accordingly.

  • B68ce3695bb8dc29b9f9cb0dc0b721a5 Murray Steele suggests about 4 years ago

    I think there's an interesting idea here, but it's struggling to poke through.

    Is this about how you test complex code? Or how you use testing to iterate from a complex messy solution down to a set of simple objects that interact in obvious ways? Or have I misunderstood the word 'test' in the title?

    I've done my share of work where I've implemented the simple case and thought I was done only to way more time adding "edge-cases" for dealing with reality and leaving my so-called "simple" solution seriously confusing. If, as your final paragraph suggests, you want to explore this I think you're onto something.