I just wrote a blog post entitled "How to architect complicated systems". This stuff seems kind of obvious to a lot of you I guess, but it really wasn't obvious to me for much of my career, so maybe it will help some others out there who are getting started with programming and system design.. Would love to know what you think!

I would normally just whip it out and adjust accordingly as you build up.

Sometimes you don't get to 'feel' your architecture until you use it. Writing it up on a piece of note is nice, but it doesn't let you feel it.

I would normally just whip it out and adjust accordingly as you build up.

Sometimes you don't get to 'feel' your architecture until you use it. Writing it up on a piece of note is nice, but it doesn't let you feel it.

My point basically boiled down to the fact that you can do that on a limited scale but when what you have to build is complex, unless you have a very clear view of how to solve your problem up front, you'll give yourself a much, much better starting point if you start out by exploring the problem domain before you start coding it. Forcing yourself to deconstruct the problem and gain that clarity in advance means that you'll have identified a good general approach and given yourself a plan of action. Not doing so means you can end up taking a lot longer to produce an acceptable result, and you'll be less likely to have solved it in a way that handles the problem completely. I don't advocate planning to the level of defining each of the functions you're going to write, I'm only saying that breaking the problem down in advance will help you to zoom out and see the general solution clearly, which will be a massive help when you start to code.

I would normally just whip it out and adjust accordingly as you build up.

Sometimes you don't get to 'feel' your architecture until you use it. Writing it up on a piece of note is nice, but it doesn't let you feel it.

My point basically boiled down to the fact that you can do that on a limited scale but when what you have to build is complex, unless you have a very clear view of how to solve your problem up front, you'll give yourself a much, much better starting point if you start out by exploring the problem domain before you start coding it. Forcing yourself to deconstruct the problem and gain that clarity in advance means that you'll have identified a good general approach and given yourself a plan of action. Not doing so means you can end up taking a lot longer to produce an acceptable result, and you'll be less likely to have solved it in a way that handles the problem completely. I don't advocate planning to the level of defining each of the functions you're going to write, I'm only saying that breaking the problem down in advance will help you to zoom out and see the general solution clearly, which will be a massive help when you start to code.

Deconstructing the problem sometimes requires you to try and code up a few initial prototype approaches to get some more insight into the problem, see what works and what doesn't, ... until you really understand what the problem "is" and how to tackle it fully. Looking at prior art can help too. Eventually you might get that moment when everything becomes clear and you know exactly (or mostly) what to do, but I find it's easier for me personally to get to that point through iterative design rather than by sitting down and exploring the problem. A lot of the time you may not even apprehend the full complexity of a problem before you actually write a prototype and run into the "crap, I didn't think of that" kind of issues.

A lot of the time you may not even apprehend the full complexity of a problem before you actually write a prototype and run into the "crap, I didn't think of that" kind of issues.

That's exactly the problem that you solve by not trying to first iterate with code. The difference with my approach is you're effectively fast-tracking the iterative coding problem by breaking down your understanding of the problem domain before you dive in and start coding. Naturally if you just start coding you're going to hit these problems and start to iterate, and I did say that if your problem domain is small enough, then this is a valid approach because it doesn't really take that long. Remember that I am talking about approaching large, complex systems. Those are the systems you need to step back from and make sure you understand your approach well before starting. If you don't, and it's a big project, you're going to waste a lot of time rebuilding large sections of the code because you didn't take the time to formulate a complete approach in advance.

So I read your blog post again and it seems you may have misunderstood me. I did not say to "code your way to a solution" and constantly rewriting everything, there is always a balance between writing code and planning ahead, one does not simply blindly code on until a solution is found. That's not what iterative design is. Iterative design is a cycle: get initial (limited) understanding of problem domain, write prototype that solves problem based on initial understanding, evaluate prototype quality and defects, become aware of difficulties inherent to problem domain and possible generalizations, make parallels with ideas and points of view you may have encountered in the past, increase understanding of problem domain, repeat. If by doing this you continually end up doing major refactorings even after several iterations then it likely means you are not using proper software development practices, are writing spaghetti code, are wasting time on perfecting prototype code, that kind of thing.

Your approach suggests doing some planning to "ask yourself questions" about the architecture, and try to make connections from pieces of the project you are working on with things you might have already done in the past, which is a good idea. But I still maintain that you cannot really (I quote) "visualise almost exactly what all of the code is going to look like". Unless you are already an expert in the problem domain, there will almost always be things you haven't anticipated, especially in a large, complex system, and you will not anticipate them all ahead of time with simple planning (if this was the case we would all be doing 99% planning and 1% planning execution aka coding). If a programmer with little experience in the relevant domain is able to sit down and plan out the entire architecture and its implementation to boot without writing a single line of code beforehand, I'd say the system wasn't really as complex as it was made out to be (your blog post strikes me as a little idealistic in this respect). And if you are an expert in the problem domain, then that means you have experience in it, which you must have acquired previously somehow.

As you can see my approach is actually quite similar to what your blog post mentions, just with more (but not all) emphasis on drawing problem domain understanding from prototyping rather than from ahead-of-time planning. Both use previous experience, of course, that should be an automatic process for every software developer (the pattern matching you mention).

Nothing is complex by itself, it's only complex in the mind of someone who doesn't fully understand the problem, so i'd go even further than you, don't tackle the problem but learn the subject untill it's no longer "complex" to you. Then only start working on it.

I agree with the cyclic designing method and making prototypes. Whenever I did detailed planning, I always made big mistakes, didn't take some yet-unknown-for-me limitations of the system/environment/language/user-interaction into account, and so on. Some times core mechanics (GUI behaviour for example) has to be changed after actual usage (not just testing) of the product.

And in many cases, these even seemingly smallest things can change major parts of the overall architecture too

Just an example: I'm programming a GUI intensive tool in Labview now, with graphs, drawing curves, etc. LAbview programs look just like any Windows programs. There's no such simple thing as MouseCapture in Labview... Can you imagine that? And everything is own-drawed, so no hWnd for the widgets. I have to either hack the hell out of the code and still not have a perfect solution, or I have to redesign the whole GUI to avoid dragging interactions altogether. There was no way to see that ridiculous limitation up front, and I also made the mistake of "yup, the usual mousecapture thing will go here and here, I will look it up later, I can't believe there's no such feature and I still can use dll calls": that would have been a single line and no question in that list that the article mentions

Prototyping is time consuming and unfortunately I usually end up using the first, second, or the third (if I'm lucky) iteration. But the next similar program will be much better. I learn tons with every single little program I make.

How to architect complicated systems: 10,000 hours of coding experience!

How to architect complicated systems: 10,000 hours of coding experience!

Haha... actually I've been thinking since I wrote my post because I've noticed a general misunderstanding of my message. I think my use of the word "planning" is a huge red herring. I've had some feedback that writing documentation and making lists is not all that helpful compared to general iteration and the feedback confused me because while I advocated the use of bullet points and spending time following this process before starting, I wasn't ever intending to convey that iteration is a bad thing, or that you won't have any cause to discover and iterate. I also wasn't suggesting that you should write documentation or that the use of bullet points was analogous to making a list of tasks to complete. Bullet points are an exploratory tool in this case.

But I still maintain that you cannot really (I quote) "visualise almost exactly what all of the code is going to look like". Unless you are already an expert in the problem domain, there will almost always be things you haven't anticipated, especially in a large, complex system, and you will not anticipate them all ahead of time with simple planning (if this was the case we would all be doing 99% planning and 1% planning execution aka coding).

That quote of mine suggests that I was too hasty in hitting "publish" and not making sure that my words mean exactly what I'm trying to convey. When I said "what all of the code is going to look like", I meant from a 30000 foot view. I meant in terms of what sorts of data structures you're going to use, what components are going to talk to each other, etc. The literal lines of code you write are minor implementation details and are just manifestations of the "plan" that you have come up with. I know that you can't know all things ahead of time, and that all things you create can be refined and improved as you gather information.

My point is this: Anyone can take a few notes and figure out a way to do a thing. Take it a step further though; really spend the time up front to refine your approach as best you can before you start and you'll find significant clarity that perhaps did not exist before, and you'll discover ways of solving your problem that you hadn't even thought of.

I'll probably write a new version of this post a year from now and get my message across in a better way.