So in my previous post I said that 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”?
I thought I had the answer to this question. It 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 21st.” This all seems very obvious, right? Now, let’s suppose you’re 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’s 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’re 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?
Tags: Santiago Ceria
mmm you may start without the knowledge and build knowledge in the construction. Sort of an “emerging” architecture, this architecture then becomes a product of your emerging knowledge. Of course in this case, you need to know beforehand (and communicate to the client) how you are going to be changing stuff to fit the previously unknown domain.
There is also a good reason to do that based on architect-user communication. Construction (emerging architecture) allows creating the appropriate language and a sort of high level validation with the user with something concrete to work on. That is something very difficult to accomplish with up-front design. Not to mention the common tendency in programmers to show the user how much they know about the user’s business (a common fantasy)
Just my 2 cents
I think this is a really interesting question. Let me propose a few different ways of looking at it.
First of all, I think that in a sense you always do design and planning up front – it’s just a question of how much. And I think that the agile answer to that is that you design until it stops being useful – when the design itself is taking more time time than it’s worth, or will create a maintenance challenge that takes more time than it’s worth, etc. So the question is where that point comes in each of these scenarios.
In the scenario where you are very familiar with the domain, you probably know fairly well where that point is. Previous projects have probably surfaced what needs to be designed in advance, and you know what things are well-understood by the team so you don’t need to spend the time making them explicit. For example, the team might say “In previous projects in this domain we’ve run into trouble because we didn’t know what stages the account can go through and what their implications were”. So the team might decide that they should spend the time to create a state transition diagram because they know that is likely to be an area of confusion or complexity.
In the other scenario, the team might decide to spend some time to research the new domain, and then begin a baseline architecture. At some point in the design process, they might realize that they don’t know enough to productively spend their time designing – that is when they should start coding and getting feedback. That is, at the time when the uncertainties outweigh the benefits gained by further design. In other words, this is about the marginal utility of additional design work.
One note on the second case, though. When it’s time to drop the pencils and start coding, it’s often best to begin the coding experiments with a hypothesis. In other words, if you are coding to learn more about an issue in the domain, sometimes you should have thought enough about the design so that you know exactly what proof of concept will answer the important questions. Having a baseline architecture in your head can serve as this sort of “hypothesis”. Your experiential learning should be highly targeted.
Thanks for raising the question – it’s a good one!