Software Development

I've started up my construction project and I learn something new every day being a programmer and all. I've actually learned a lot about programming by doing manual labour. This surprised me at first. And not only do I get in better shape, but it's good for the brain too!

On any job, you have to coordinate who does what. Being in groups of two works best. Something that becomes clear very early on is that if you have more than two people and no one who is officially in charge, you get into problems. Not that this happened. It's when analysing who does what and if we need more people (because some people offered to help), we couldn't figure out where we'd put them and because we're on a tight budget, we have to make sure everything goes well. So coordination is a must.

The point is this. Small jobs coordinate themselves. Large jobs do not. But look at the word I'm using: JOB! What is a job? It's a list of tasks or operations. So doing a construction job is basically real life imperative programming. Small jobs are simple and you can do with very little coordination. Larger jobs need someone to take control of what happens.

It goes beyond this. Even large jobs have limits. The really large jobs that succeed are the ones where much of the work has been standardized or the methods are well known. There is simply no way that you could succeed if you had to check up on every single person all the time. But this is exactly what we're expected to do in programming. Check exceptions. Check error codes. Check input values. Check return values. Trust no one.

There are some uber real life imperative programmers out there. One thing that is very clear is that this is definitely NOT the norm. And note how the thing they are building is "worked on", not a series of continuous operations that is the purpose in of itself. Once something is built, you can add onto it. Road networks, houses, land, etc... they just are.

People come and go, but buildings, roads and land are forever. This sounds exactly like an old quote from someone (can't rememeber the name) that works for Oracle who said software come and goes, but data is forever. And it's true. If we are to break the barrier to larger scale software, we need to build it in a way that's known to work in the real world. We need to have the actual "thing" just be. We need to be able to connect and piece these things together in a certain manner that makes sense without software attached to it. At least, not all the time.

The reason being that anyone at any time can come and do some work on this "thing". Software today is rather monolithic in nature. There can only be one controller, and for all the reasons I gave above. But for massive scales, you just cannot do this. Nothing in the real world works this way. Yet we believe that software is different. There's a real reason why software size has a limit. Also, I truly believe that the only significant expansion of software size has been due to certain tasks being so common that it's been standardized. However, I think we must be careful to attribute this progression to language design or any language feature. It is but a side-effect of a growing industry.

To go beyond, I really believe that data must be at the core of what we are building. That there must exist a way to connect this data together in a more meaningful way that goes beyond languages. In this manner, any language and any tool can come in and do the task required. When you're dealing with physical objects, real life smacks you in the face as to what is feasible. Software isn't so obvious, but I see no reason why the rules would be any different. The primary worker is still human.