Big Up Front Design Considered Scary Beyond All Belief

I had never before been able to put into words why I really hated it when a senior developer (Mr X) I worked with demanded I had a Big Up Front Design before I wrote any code, but I knew it irritated me to the core.  Because Documentation is a Good Thing™ right? Except that I am now trying to work alongside someone on a particular project (whom I shall call Mr Y), who is still under the influence of said senior developer.  I’m trying to help Mr Y  to produce a design which will satisfy Mr X so someone can eventually get around to the task of implementing the thing.

I’m not saying all design is bad, far from it!  I just think that most capable developers are really creative people who like to battle with the machine.  They are, in my humble opinion, considered capable because they’re constantly analysing their design and making tiny adjustments where necessary.  Even tiny things like changing that function parameter to be “const” because we’re not modifying it is almost entirely what I would call design.  The function would do the same job without that modifier, but now the signature more eloquently describes its intentions.  So what I’m really saying is that I don’t think design and implementation are separate activities.  This shouldn’t be revolutionary at all, but evidently from what I’m now observing, clearly there are some people who still believe it to be true.  Based on this thinking, I thought I was going to coin a new term: “Continuous Design”, but a quick google showed me there’s already a wikipedia page.  I guess I can’t add myself as a citation now!

So, let’s explore continuous design briefly.  To me, it’s the slight adjustments made as we discover new information – this necessarily and even especially includes the ‘implementation phase’.  If we remove ourselves from reality, as Big Up Front Design tends to do, the creation of the design document often becomes more important than the design itself.  That diagram needs to be neater.  This paragraph is too ambiguous to code.  If I’m being honest, I don’t care if you have a document explaining how you’re going to code something up.  I absolutely care if you have a document describing a protocol, and it would be nice to have a document explaining why you’ve coded something that way.  However, there are these handy inventions called comments which I am more likely to read, and indeed, trust. So designing continuously to me is that little bit of refactoring that you do to tidy things up.   It’s the slight adjustment that stops you from veering too far to one side.  It’s the comment or well chosen name explaining why this function exists! Sometimes it’s not even a conscious thought, it’s more likely labelled as “cleanup” but it all helps the readability, maintainability and extensibility – which are the only reasons we care about design, right?  Some of it is more deliberate – I’ll change the signature of that function to take in a buffer, because populating a global and returning a pointer to that is probably dangerous in a threaded environment.  But neither of those two cases deserves to be described in a document, so I hate it when people try.  Especially when they ask me to read this watered down version of the truth, which in the back of my mind, I know I can’t trust, thus asking me to waste my time reading it.  I think that this is the reason that I hate “interface definitions” prior to the implementation being started.  They’re often a watered down, happy path version of the true reality.

But getting back to the problem at hand; what I’m largely seeing is the context of decisions melting away.  So assumptions on how things work are starting to creep in, to the point where I had to start quoting areas of the code base in emails to drive my point home.  That scares me, because it means I’m having to read the code to them, which makes me worry what other context is being missed as part of this design.  I understand that we as a profession are really bad at reading code.  Most of us think we’re pretty good at it, but if we’re honest, true understanding of the behaviour only really seeps into our thick skulls after we attempt to modify it – that’s certainly true for me.  The less code you understand, the more assumptions will affect your design choices.  And unless you have some wonderful person on the other end of the email wire willing to quote the relevant pieces of code to you, your design will be broken.

This context loss is all pointing to one very disparaging idea.  Mr Y is trying to design the extensions to the subsystem without getting his hands dirty.  He doesn’t understand many of the fundamental interactions because he hasn’t had to piece anything together.  He also appears to be using fear as a synonym for risk.  He seems to be mitigating the ‘risk’ by investigating himself right down the rabbit hole, producing many detailed documents, state machine diagrams and an almost endless supply of stories on the backlog to investigate areas he uncovers as he investigates.  As someone who understands the code, I was asked to review these documents to evaluate their usefulness as a fountain of truth, and their level of detail and complexity made me feel like the Maitlands from Beetlejuice in the picture to the right.  What I don’t feel he’s doing, is furthering his understanding (or indeed anyone’s who is tasked with reading these monsters)  to the point where he can make good decisions on his own.  So his fear is driving him to investigate rather than get stuck in and try something – which I don’t really blame him for.

Hang on a second.  How can it not be the fault of the individual when it’s fear driving decision making?  Simple.  The abuse and misunderstanding of several different viewpoints from the several different consultants hired recently have all collided into the impression that if we just do these couple of things like use Agile Methods, Set-Based Concurrent Engineering, Test Driven Development, Record Our Technical Debt, Continuous Integration, etc, etc then everything will be Just Fine.  These are all Good Things™, until they’re used as excuses for not doing anything.  These are all supposed to be ways of getting things done, not ways of avoiding making decisions.  Fear isn’t exactly driving the decision making, it’s driving him to make no decisions at all.  Making the wrong decision and causing instability, however minor, is such a hated thing in my company, such that nearly all of the “design output” I’ve seen to date has been trying to capture in excruciating detail the current state of play, in an effort to not put a foot wrong.  This is despite the fact that the “protocol” and the “why” documents were produced by the people who last worked/are working on it.  It saddens me that all these well-tested practices are being used as a way to slow down development, not speed it up, without actually producing anything real to date.

I think the point I’m heading towards is that Big Up Front Design is Scary Beyond All Belief because you can do it so easily in isolation.  In isolation from reality, isolation from the truth, in isolation from the other people who are working on the project and in the worst instances, in isolation of actually producing anything of value.