I've been reading Dreaming in Code lately, and I really like it. If you're not a dreamer, you may safely skip the rest of this post ;) In Chapter 10, "Engineers and Artists", Alan Kay, John Backus, and Jaron Lanier really got me thinking. I've also been thinking a lot about Minix 3 , Erlang , and the original Lisp machine . The ideas are beginning to synthesize into something cohesive--more than just the sum of their parts. Now, I'm sure that many of these ideas have already been envisioned within Tunes.org , LLVM , Microsoft's Singularity project, or in some other place that I haven't managed to discover or fully read, but I'm going to blog them anyway. Rather than wax philosophical, let me just dump out some ideas: Start with Minix 3. It's a new microkernel, and it's meant for real use, unlike the original Minix. "This new OS is extremely small, with the part that runs in kernel mode under 4000 lines of executable code.&quo
Comments
In Canada, where engineering is a professional discipline with legal backing behind it (ie. it's illegal to call yourself a professional engineer if you haven't met the correct accreditation requirements), this is a large part of Software Engineering.
Software Engineering recently became a professional engineering discipline, and while most of the focus is on formal methods, you also *have* to take multiple classes on physics, chemistry, mechanics, thermodynamics, ethics, etc.
A Software Engineer should not be an expert in any of those fields, but must be able to work with domain experts to implement a solution in software.
There are no physics laws governing software in such a way as to guarantee that the safeguards are "strong" enough to keep the software from falling over. I know if a bridge is strong enough; I don't know if a piece of software is strong enough.
It's a young field that still needs a lot of work, but you have to start somewhere. We'll probably never have a software equivalent to f=ma, but you *can* formally prove software designs. It's just really really hard.
Take a look at the invention of steam engines, they were prone to explosions, and most of the refinement came through practice, observation and refinement. I'd challenge anyone to say this is the actual process of engineering, and not very different from what software engineers do.