I recently set a challenge ... describe how you design software in the time it takes you to have a coffee break. I've posed this same question to a few people myself and answering it is really tough. And that, I think, is kind of worrying. Related to this is my observation that teams now find it easy to visualise the software development process but not the actual software that they're building.

We used to have a reference point

If you look back 10 years or so, a number of teams were using the Rational Unified Process (RUP). Don't worry, I'm not about to start evangelising RUP but it does have a number of very useful elements and it gave software teams a reference point for the software design process. As a real-world example, I worked on a fairly large RUP project a while back and, as you can imagine, we spent a long time producing documentation and UML models in order to come up with the design for this particular enterprise Java system. I don't remember what the trigger was, but eventually we had some consultants from Rational come in to help us and they provided advice on which RUP products we should focus on in order to streamline the software design process.

As an aside, I met Uncle Bob for the first time when he was in London recently and we had a quick chat about this sort of stuff. The "boundary, controller, entity" approach that he mentions in his clean architecture talks is exactly the approach that the guys from Rational recommended that we take. In a nutshell, they gave us a set of simple steps for transforming use cases through to high-level software designs, which could then be implemented using enterprise Java.

Look back even further than this and you have all of the notations that preceded UML, data flow diagrams, entity relationship diagrams and higher level methods like SSADM. Again, you can consider these as reference points and guidance for the software design process.

Where is our reference point now?

Many of my thoughts about the current state of the software development industry are summed up in The frustrated architect so I won't repeat them here. What I will repeat though is that many software teams have thrown far too much away in their haste to adopt "agile". UML and documentation are typical examples of something that is being thrown away by software teams on a daily basis. After all, 3 months spent creating UML models is 3 months where the software (and value) isn't being delivered. That's all fine, but agility and, therefore moving fast, requires good communication yet many software teams now struggle to articulate what it is they are building and how they are building it.

If we can't articulate how we design software, we can't teach it

So how *are* teams designing software? They obviously *are* designing software because I've seen it! Occasionally I'll hear "we do something like domain-driven design". More usually though, teams tell me that they "draw some pictures on a whiteboard", to which my response is "how do you decide what to draw?".

If you've seen me speak, you're likely to have heard me talk about how the software architecture role should be about collaboration, coaching and mentoring. Why? Because we're losing the software architects of tomorrow and coaching is key to reversing this trend. But if we can't articulate how we design software, how are we going to teach this skill to others?