Disruptive design paradox

Everyone knows SW design is important. Taking the right decisions in the beginning of the project is a key to its success. But the reality of the disruptive team is ruled by lack of information on the nature of the problems, and the available tools. And on the other hand – this same lack of information drives higher manager’s nuts – they will want to see something quick. They will not want you to wonder around for weeks exploring possible designs in ordered process. 

There are two known extremes:

• An ordered process where there are requirements, design and implementation stages, meeting and documentations - when time’s allowed
• A chaotic process where the engineers just jump into the code and play with it

Many think the 1st way is the ‘right way’ – and explain in shame how they are working according to the latter because they don’t have enough time. Maybe it’s even someone else’s fault?

In reality – there are many in-between possibilities. Conducting a 2h brainstorm on a module, where the team explores possible designs will have a great benefit – even if most of this design will never materialize. You will define and get some common language. And if someone in the future will need to implement a module – he will have a vague context on its role within the big picture. Define the interfaces and modules; assign meaningful names (commonly known patterns and new metaphor inspired ones). Everyone should try to imagine they are indeed designing the long term implementation. At the end – you might simply pull your camera-phone and capture the diagrams from the whiteboard. Possibly everyone will now go back to the crappy work – but it will almost always be worth it

On other cases – the team might only quickly implement the abstract interfaces. Defined interfaces are ½ of the benefit of proper design. 

If the decision making is still hard – consider making 1-2 pilot efforts: where engineers take concepts at full steam for a few days. A good approach will usually ‘feel good’ after only few days of implementation! (“Jon implemented it last night – it’s more or less working today! Man it is so much straight forward this way – why didn’t we do it earlier?!”)

For some reason – many times I face strong resistance to this simple process: “why are we wasting our time in designs?! There is no time!!!” or “This is a waste of time… let’s take a 2 week break and make the design properly!” or “you don’t have time for that – I need to show this demo working by tomorrow!”

The manager’s role here must be the responsible one. Try to see how to push away the pressure a bit to allow the rapid design stage to happen as it almost always worth it. Yes – your role here is to look beyond the words: think what will actually happen, what will work, who can accept what, and suggest your superior on alternative timelines that you think they could accept. Your reporting engineers must know you have the ‘full picture’. You can bring the hysteria to a sane level. You are the leader – and in time of crisis – you work according to your strong narrative. (The product, the real needs, the real goals) This will be the ‘real picture’ and it can be reflected both upwards and downward in the command chain.