4 ms·

Caveat: I’m a high school drop out with zero college and poor study habits. I’m a consultant and have a tendency to spout bullshit from time to time. I’ve been

Caveat: I’m a high school drop out with zero college and poor study habits. I’m a consultant and have a tendency to spout bullshit from time to time. I’ve been striving to find a set of fundamental laws or first principles for software development for several years now. I don’t think we should confuse a need for first principles with physics itself. I see no benefit to finding parallels between each aspect of physics and contrived relationship with software. What I humbly believe is necessary is an understanding of the natural fundamental laws that come into play when making software. These would be evidenced by natural observable phenomena. I believe that most of these laws WILL NOT COME FROM COMPUTER SCIENCE. This is because making software is more than computer science. As a brief introduction to my thesis let’s consider what things come into play when making software and their relationships to each other. Then let’s consider the areas of study which come into play for each relationship. We have humans, computers, and software. There are fields of study for each relationship. Humans <-> Software (HCI, semiotics) Humans <-> other Humans (group psychology, language) Humans <-> themselves (positive psychology, et.al.) Software <-> groups of humans (complex adaptive systems, economics, ?) Software <-> computers (computer science, computer engineering) Computers <-> other computers (networks, information theory) Software <-> other Software (complex adaptive systems) If we look at each of these fields what laws or axioms can we find that come into play when making Software? Can we reason logically from those principles into a better understanding of software development? Perhaps some kind of field theory? That would be nice.

Jtsummers 9y ago
Software engineering is almost a pure design activity, compared to every other engineering discipline which ultimately results in manufacturing and assembly processes at some stage (software build systems are not the same for various reasons). Software also suffers in that it is largely unconstrained by physics. If I want to design a new car I am physically limited in how components can interface with each other. The same constraints are largely lifted inside a computer. I can write a module that interfaces with 5000 other modules directly (it'd be horrifying to maintain, but it can be made). In order to get a handle on software engineering, we have to introduce artificial constraints into our process. Systems engineering and the other engineering disciplines already have these constraints built-in (what materials are available, how does physics work, what kind of power can we actually send down a wire of certain gauge and metal). What sorts of constraints do I mean? Well, first is simple the structured and modular code of old. This just makes reasoning about the system much easier. The second is things like layered architectures or designing to interfaces. By having to narrow down my activities and communication at and across boundary layers I force myself to come up with either more reasonable designs or something horrifying. Hopefully I go for the former. You can also introduce constraints via our languages (this is going to come out of CS). Static type systems introduce a constraint. These force you to negotiate with the type system and be more deliberate in your decisions. A dynamic type system or duck typing lets you get away with a lot of things (for good or ill) that can produce hard to maintain systems and hard to reason about systems. Does this mean we need static typing everywhere? No. But if we don't have it, we need to find other ways to constrain ourselves. Perhaps it's with conventions. Thou shalt have 100% code coverage in unit testing! If it's not covered, you have to get it covered before it can be integrated into the master branch. Practices help. TDD introduces a physics to the world of your code. TDD may result in a test that says: It is a violation of the physical universe I'm creating for this module to ever change this value (say you're using shared memory across multiple threads, processes, or objects). Obviously, it can be violated, but your test tells you when this violation occurs so you can address it. Much like a CAD system may help a vehicle designer realize that the door cannot open because it will hit some other object. Sure they can place the door there, but physics will not allow it to behave the way they want it to. Ultimately, to engineer a system is to design within a set of constraints. We need our software to be constrained in order to start engineering it. There will be no single set of constraints for every activity (see Fred Brooks' No Silver Bullet). But there are activities and techniques we can use, language options, etc. that will help within and across many of our programming domains.

Jtsummers 9y ago

Software engineering is almost a pure design activity, compared to every other engineering discipline which ultimately results in manufacturing and assembly processes at some stage (software build systems are not the same for various reasons). Software also suffers in that it is largely unconstrained by physics. If I want to design a new car I am physically limited in how components can interface with each other. The same constraints are largely lifted inside a computer. I can write a module that interfaces with 5000 other modules directly (it'd be horrifying to maintain, but it can be made). In order to get a handle on software engineering, we have to introduce artificial constraints into our process. Systems engineering and the other engineering disciplines already have these constraints built-in (what materials are available, how does physics work, what kind of power can we actually send down a wire of certain gauge and metal). What sorts of constraints do I mean? Well, first is simple the structured and modular code of old. This just makes reasoning about the system much easier. The second is things like layered architectures or designing to interfaces. By having to narrow down my activities and communication at and across boundary layers I force myself to come up with either more reasonable designs or something horrifying. Hopefully I go for the former. You can also introduce constraints via our languages (this is going to come out of CS). Static type systems introduce a constraint. These force you to negotiate with the type system and be more deliberate in your decisions. A dynamic type system or duck typing lets you get away with a lot of things (for good or ill) that can produce hard to maintain systems and hard to reason about systems. Does this mean we need static typing everywhere? No. But if we don't have it, we need to find other ways to constrain ourselves. Perhaps it's with conventions. Thou shalt have 100% code coverage in unit testing! If it's not covered, you have to get it covered before it can be integrated into the master branch. Practices help. TDD introduces a physics to the world of your code. TDD may result in a test that says: It is a violation of the physical universe I'm creating for this module to ever change this value (say you're using shared memory across multiple threads, processes, or objects). Obviously, it can be violated, but your test tells you when this violation occurs so you can address it. Much like a CAD system may help a vehicle designer realize that the door cannot open because it will hit some other object. Sure they can place the door there, but physics will not allow it to behave the way they want it to. Ultimately, to engineer a system is to design within a set of constraints. We need our software to be constrained in order to start engineering it. There will be no single set of constraints for every activity (see Fred Brooks' No Silver Bullet). But there are activities and techniques we can use, language options, etc. that will help within and across many of our programming domains.