So in my previous post I said that nowadays there are fewer cases when building models before
Nowadays there are fewer cases when building models before building the actual code of an application makes sense. In which cases does it make sense? More explicitly,
in which cases should we spend a significant amount of time creating architecture and design
models before we run to code?
Let’s ignore for a while safety critical applications and “for other reasons very critical applications”, the easy answer to the question (I know that more and more applications are becoming critical, but still I want to focus on the other ones, at least for this post).
My question is equivalent to asking “when do we need significant design up front”? The answer to this question goes something like: “The more you know about the domain you are working in and the reference architectures that make sense to that domain, the less time you need to devote to design up front”.
When you’ve built 20 web applications using .NET that have similar functionality, you won’t need to design a lot before you start working on the 21 st .
All this seems very obvious, right? Now, let’s suppose you are facing a problem in a completely new domain. You’ve built 20 web applications and now someone asks you to build an application to control the movement of a robot’s arm. No database, no front end, a real time operating system… all new.
I had a similar problem a long time ago, and I remember how terrified I was when facing the empty whiteboard in our first design session.
So, what do you do in this case? My answer goes something like “In these cases you can’t jump to build something because you don’t even know what languages or communication mechanisms you should use, what you have to do is to look for reference architectures for the domain, learn about the domain and how the solutions for that domain are usually structured, and try to come up with a specialization of that reference architecture that can solve your problem. Until you figure all that out, there is not much you can code. It would be a waste of time”.
So, according to this theory, Design up front seems to be related with the knowledge of the domain and the technologies used in it . In the first case you don’t need to spend a lot of time on design because you already know the reference architectures for that domain. You already have a design in your head.
In a meeting last week I said all this to a group of software professionals and, when I proudly finished my explanation, one friend who has a lot of experience in software development, much more than I do at least in the technical side, said: “I’m sorry to say this, but I disagree completely with what you say. I think it’s exactly the other way around. When you know a domain and the technologies that work well in it, you can spend time on design . There’s not a lot you can do wrong designing. But if you are working in an unknown domain, you have to start building something very small , as the chance of making mistakes is much higher. In the case of the robot, I would start by building a very simple functionality, something like moving the arm one inch. And then I would grow the system from there”. Long silence…
I won’t say if I changed my mind after hearing that. And you, whose side are you on?
Comments? Contact us for more information. We’ll quickly get back to you with the information you need.
