updated almost 6 years ago; latest suggestion almost 6 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 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.
: Let's define that as something that makes money but that you feel an increasing urge to walk away from.
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.
I suppose I want to talk about complexity in particular rather than testing per se so have edited my proposal accordingly.
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.