Increasing Complexity Over Time
Posted: January 27, 2008 Filed under: General | Tags: complexity, knowledge, time 2 CommentsIn Dianetics, L. Ron Hubbard mentions:
Only things which are poorly known become more complex the longer one works upon them.
Have you ever seen that happen with a software project? It just becomes more complex, and more complex, and more complex, and eventually it’s just a huge mass of complexity that nobody can maintain anymore?
I think it might be interesting to think about that in the context of the above quote. Perhaps there’s actually something more that could be known about the system. Maybe your users don’t actually need or want all those features. Maybe there’s more research that could be done on different areas of the system. Anything, really–just know more about it. Maybe there’s even some fundamental missing data about life or programming that’s hampering the project.
Whatever it is, I think it’s pretty interesting to think that knowledge could defeat complexity!
-Max
Complexity to Fix Complexity
Posted: January 13, 2008 Filed under: General | Tags: arbitrary, complexity, design, hacks 4 CommentsIn Dianetics: The Modern Science of Mental Health, L. Ron Hubbard discusses a principle called the Introduction of an Arbitrary:
An aribtrary structure is one in which one error has been observed and an effort has been made to correct it by introducing another error. In progressive complexity, new errors must be introduced to nullify the evil effects of old errors.
How many times have you seen this happen with a software project? It’s poorly designed in the first place, and then somebody discovers an error. Instead of fixing the design, they tack on some “hack” to fix the error. In other words, just like Ron says, they keep introducing new errors.
It’s long been known that this is a bad idea, but the new idea here is to look at this as a process of introducing errors. Just because some code “fixes a bug” doesn’t mean that it’s not an error to write code that way. You are actually introducing new errors into your program every time you “hack” in a fix instead of fixing the real root cause of a problem.
I think most professional developers have long felt uneasy with “hacking” in a fix, but perhaps didn’t quite have anything to back them up when they protested and said, “I just want to fix it the right way!” However, if we look at “hacks” as errors, then it becomes easier to see why the “right way” is the right way.
So in the future, when you’re fixing an error, don’t introduce new errors to fix it. Do things the “right way.” 🙂
-Max
Theta Code 