I’m curious to see your thoughts on the broad question I posed here:
My background is in UI development, writing a lot of iOS apps, so I probably run with a different crew than most of the people on this forum. I’d love to hear your perspectives.
4 Likes
I’m a beginner programmer and this entitles me of saying stupid things with no consequences, so here goes 
In my opinion… software should be written in terms of self contained units of computation.
Like small bubbles with inputs and outputs.
This is why I like the idea of processes and message passing.
As far as I know OO is trying to put abstract things in a box and hope they never change in a huge system.
As the internet of things is about the hit the interwebs, there’s no telling what kind of madness of data there will be out there and is it possible to produce a system that can change fast enough to take advantage of both the data and the different ways it can be used.
So I really like to think of this in biological terms, another area I’m not an expert in, so I can say stupid things about it too 
As far as I know, the human brain doesn’t process 100% of the input it receives from sensory data.
So it has inputs that convert outside data to useful signals for the brain, then the brain picks and chooses what it likes with pattern matching, and so it outputs a product that makes sense for itself.
If there’s a system that can take inputs as diverse as the universe and can output something meaningful, I think it’s worth looking at for inspiration 
Maybe the key is not to change yourself all the time in order to make sense of the ever changing outside world, but rather to change the perception of the outside world in order for it to fit in whatever makes sense to you.
So in my programs, I will try to write processes that convert all possible input, to something meaningful for the system and then the system will be capable of choosing stuff it makes sense at that moment.
I guess that’s all the stupid things I can say and get away with it, so hopefully I’m not getting shot after this
4 Likes
Embrace the Unix and Erlang/Elixir philosophies 
Do one thing and do it well, and be self-aware (sort of like BEAM processes) 
3 Likes
Thanks for sharing your ideas!
2 Likes
While the universe has many agents who can destroy a stone spiral, code generally only gets worse when people touch it.
Besides the obvious “write tests”? It won’t KEEP the code from going entropic, but it’ll TELL you when it happens, then it’s still YOUR responsibility to fix it.
Careful maintenance and attention to design will help ensure that people are less likely to break things.
As a manager of sorts, shielding the team from pressure, providing them with a clear direction and letting them decide how to get there, and giving them time and money for professional growth: all of those things will help with making sure your code doesn’t rot.
3 Likes
Great insights, Trevoke. I like how you tie in the personal aspect of the development process. Another thing to consider is that not only the code is subject to entropic decay. A running system is also able to “rot” due to persistent side-effects, such as data corruption. Clearly the code and the run-time state are intimately related, but they are distinct concerns.
1 Like
It’s worth noting there’s a whole book that addresses system stability, though not quite from the angle you address. It’s called Release It by Michael Nygard, and it’s a very important read when you’re building anything even slightly complex.
2 Likes
Thanks I will definitely check that book out.
This made me think of ‘Just a bunch of rocks’, which is my absolute favourite XKCD comic.
Back on topic:
As for what one can do to defend your creations against unceasing entropy, I think that this is one of the main reasons we write tests: Well-written tests let us show whenever a rock gets misplaced (and which rock it is), so we can re-arrange our spiral to keep working with little effort (as opposed to at some later point realizing that the spiral doesn’t exist at all anymore).
Still, there will be events like the Y2K38 problem that will break a lot of things and are very hard to migitate. We, as high-level programmers, really do depend on a lot of different infrastructures cooperating in just the right way.
2 Likes
Great comic & excellent points! Thanks for the feedback. I fully agree about the role of automated tests as a safety net.
