UKtramp:
Rjan:
And when was the last time you saw a jigsaw puzzle designed and fabricated piece by piece? One starts with the whole, applies paint, and cuts it up. To do it the other way around, to have a team work in parallel, painting each piece and cutting its edges irregularly, would make it almost impossible to integrate. A patchwork quilt is a better metaphor for the approach you describe.
It is not as straightforward and effective as you think to achieve a division of labour on the design task, and still maintain the necessary integrity.
It is a common programming practice and is exactly how it is still done today. Lots of reasons why it is done this way, but yes it is common program design for complex issues and is extremely effective. A patchwork quilt? That may be a good description but a jigsaw I describe is probably the best. Each piece is joined together, the jigsaw is not designed piece by piece and put together, the program is designed in pieces and the pieces are put together like a jigsaw. It is the programmer that programs the pieces from the design, the pieces are joined easily and seamlessly, That is the beauty of the programming environment and software suit. Debugging takes care of the piecing it all together.
My point is this, that design-by-the-piece creates only the illusion of a reduction in complexity - unless the pieces involve very loosely coupled problems with minimal or no interacting or cross-cutting concerns, which is the case only infrequently (and certainly wouldn’t be characterised as a jigsaw problem). Complexity returns to the stage when the time comes to integrate the resulting design-pieces which, having been conceived to address their own concerns separately from the concerns of the whole or of the other pieces with which they must connect, will be disjoint - it would be marvellously coincidental if two jigsaw pieces cut separately in separate rooms were found to couple.
The integration of any two irreconcilable pieces by redesigning them in conjunction with each other, may not only lay waste to most or all of the design work that was done on them separately, but the modified design of the piece-combination may cause a third or any number of other pieces to become newly disjoint.
And the design of the piece-combination will be subject to some unholy combination of the constraints that applied to the design of each piece separately, meaning that further modifications to the design of the piece-combination (in further rounds of redesign-to-integrate) are substantially more constrained.
With each successful integration, the inertia of the design of the so-far-combined pieces must grow, the number of design constraints operating must grow, as does the amount of waste if redesign and reintegration becomes patently necessary (which with each extra piece becomes more likely and not less), and the complexity of the design challenge steadily approaches what it was when the proposal was first made to break it down into pieces to make it simpler.
Rjan:
So how did you cope with making tea that isn’t in a bag, and did you teach it to recognise and recover from a broken bag? Can it get the cup from the cupboard, or from the dishwasher? Can it recognise when the handle has fallen off the cup, or is cracked and about to? Can it add sugar? Can it add milk, and recognise when the milk has curdled? The list is endless, as it is with describing how human bums are wiped. A machine does not necessarily have to do all these things to be useful, but the less it can do, the more supervision it requires, the more its environment must be controlled, the more frequently intervention is required, and the less it can be integrated into a wider automatic process.
The tea program took all of the design issues as real world programs take to design and put together. The complexity of each stage is designed and programmed and tested, debugged before becoming a piece of the jigsaw ready to fit with the next programmers piece.
For example, you may say fill the kettle up and switch it on, well this is not as specific as needed for the computer. You have to give the exact quantity of water to place in the kettle, where is the water, how does the water fill the kettle, through removing the top or poured through the spout, then where is the water taken from, a tap or a bottle, where is the tap or the bottle, how do you turn on the tap, two turns right or one dial switch etc. You get the idea. So each piece of this complex program is split into sections, of filling the kettle, placing tea bags in a cup etc etc. All of the variables of each stage are then tested for what if. It is very labour intensive and so you can see how expensive software is to design and program from the initial concept to final product. This is why billions will have been invested into autonomous vehicle design. I am an ex programmer and was lecturing on program design up to 5 years ago. It is still the way it is designed today. It comes across to me that you are familiar with possibly web design issues? I may be wrong but that is how it appears as if you were involved with programming as I was, we wouldn’t be having this debate, so no insults please as I am trying to get where you are coming from and what level of programming you are knowledgeable with so I can pitch my experience to that. Bear in mind that I have no real expertise in autonomous vehicle design, the principle of program design in both structure and design issues will be very similar throughout so I can speak of this concept.
I don’t perceive any insults. I am just an armchair philosopher, and what I’m talking about is actually as applicable to complex bureaucracies that don’t involve computers. Feel free to address me at any level, but beware that I may be addressing you on territory that you are not particularly familiar with.
I suspect your time as a lecturer was spent explaining what software can achieve and how to implement the latest design fad, not least because education nowadays is supposed to deliver mass-marketable skills, and not discussing why projects routinely fail to achieve their goals or blow budgets (often both), or why outcomes like clean bums which are seemingly straightforward for humans to achieve are difficult or infeasible to model as physical processes - certainly more difficult than training a dog to ride a unicycle, which is difficult.
IE garbage in garbage out.But which to a human who understood the meaning was anything but garbage.Luckily for us the German Navy having been too stupid to realise it and use the same method instead of mathematically crackable codes.The fact is the human brain and the body it’s connected to is superior to computers whether talking in code or driving or flying a plane. 
