How to Apply Incremental Modular Design to Global Challenges

Incrementalism, or muddling through, is a very important concept, but it has its problems. The problem is, if you're going to  do a project in lots of small steps,   do you have to get funding for each step?  Because that is sort of the way it was   described, as if instead of getting one huge  pot of money, let's get small amounts to do a small step and then another small amount and then another small amount.

That way if a step doesn't quite work properly, it's a small amount – people don't care so much as if it was a big project and you failed in the first step or two. But it's really hard to raise money. And it's easier to go and get 10 billion dollars in one pass than it is to get – you know – a hundred thousand dollars many, many, many times. If the political agendas all come together to be able to support this one big project,

you'd better take advantage of and take the money when it's available, because the politicians will change, the  problems will change, the finances will change, and maybe you'll never get another chance. So, but how do you get this big money and not do a big project that loses flexibility? And I looked around, and there's one other field that often deals with huge projects requiring hundreds of people for many, many years, and that's software development.

For large companies doing an operating system or doing any complex computer system requires in many ways the same kinds of issues with many different disciplines involved; it takes many, many years. And how do they do it? So, I borrowed three different techniques. First of all was a notion of incrementalism or muddling through. Second was the notion from the programming technique called Agile with this notion of the *minimum viable project*.

And third was a notion that comes from the kind of programming called *object-oriented programming*. So, first, incrementalism, on how we should do this in small steps so that we can take, we can understand what we've accomplished in that step and then maybe modify what we'll do for the next step, but keep doing small steps, and make sure it's in the right direction and the next step in the right direction, which gives us the flexibility to change as we're doing these things.

Second, if you look at the Agile programming status, how do they do it? What they do is they take this huge, big programming problem and they divide it into very small chunks, but the chunk has to be working. So, if you're doing a huge accounting system for, I don't know, the income tax of a country, well, let's take one small little piece, one small little aspect, and you have to go from the beginning to the conclusion.

So, it has to be a workable system even though it may just be such a tiny insignificant piece that actually can't really  be used on its own, but it works on its own, so you can demonstrate that you're in the right direction. So, it's called the minimum viable project, which means it's a minimum system you can build that actually has a usable, sensible result, but that way you get evidence that you're  on the right direction and that you

are capable of doing something, but it gives you the flexibility that the incrementalism and modularity requires. The third principle comes from object-oriented programming, which basically says that we make the program into small modules. Not the minimum viable principle modules but even smaller ones, but we make it so that we don't care what goes on inside, how you write the program. What we care about is, what are the inputs and what are the results, what are the outputs?

And we can change what goes on in the inside, as long as we don't change what is required information or material coming in and as long as we don't change what is required going out. So, that gives us wonderful flexibility; for example, designing – I don't know – again, a water purification stage: what we can do is we can design different things, and then for the water purification itself, well, we could fake it. We have a little module and in comes dirty water and out comes clean water.

And we could do it with, I don't know, put people inside, manually cleaning the water. It's a good way of testing what you've got, so you have some modules that are completely finished; you have all the machinery, all the cleaning methods, all the electronics used to synchronize, etc. And you have those all working together, and then you have a couple of parts which are done by simple mechanical systems or people, and it shows you the system works. And then what happens is you can slowly modify the modules that are done by people,

say, and make that more automatic and more the way you'd like it to be. But, meanwhile, you have a working system, so you could have a working system which is, you know, half the old ways of doing things and half the new ways of doing things, but you can modify it as you have the abilities and resources. And so, these three things put together  I call incremental modular design.