Stopping a CreationPosted: March 10, 2008 Filed under: General | Tags: architecture, blame, bugs, design, fundamentals of thought, responsibility Leave a comment
In Scientology: The Fundamentals of Thought, L. Ron Hubbard says:
To stop any creation, it can be established that one once knew one was creating it (finding that thought) and making it known again.
At first, that might seem like a funny thing to apply to programming. After all, aren’t we trying to create programs, not stop their creation?
Well, yes. But there are a few things that we don’t want to create, like bugs, or bad designs. I know I’d be happier if those stopped being created. 🙂 So how can this quote help us?
Well, have you ever noticed that some programmers produce far, far more bugs than other programmers? They just can’t seem to stop creating bugs. Now, these programmers, have they ever thought back to the moment they were making the bug, and found for themselves what decision they made at the time? Have they ever really taken responsibility for having made a decision that caused a bug, or do they just “fix the bug” and never try to understand the source of it?
Many of the greatest programmers I know have an instinct that they should go back and find out where a bug came from. They just know that this is important, even if they can’t quite articulate why (other than the practical sense of “Well, it might also be affecting other things” or “It’s educational”). When they find it, if they caused it, they’ll say, “Oh, yep, that was me.” They might even explain a little of what they were thinking, at the time.
On the flip side of the coin, some of the worst programmers I know spend a lot of their time blaming others for having caused bugs. Whether the blame is right or not, it doesn’t matter, because what needs to be established is “that one once knew one was creating it,” not that somebody else knew one was creating it. You have to find out for yourself what happened!
This whole thing also happens with software architecture. Somebody makes a decision like, “Okay, we’re going to design this poorly because we’re crunched for time.” Then, years later, they wonder why that part of the software is so hard to maintain! They never went back and took responsibility for having made that decision, they just hacked and patched and fixed–in other words, they kept on creating the bad design.
Often, it seems like there’s no way to handle bad designers or poor programmers. That they’re just hopeless and have to be let go or removed from the project. But maybe–just maybe–something could be done about it by teaching them to go back, note “Oh, right, I did have a thought about creating this,” and then get on with making it better or creating something new.
Complexity to Fix ComplexityPosted: January 13, 2008 Filed under: General | Tags: arbitrary, complexity, design, hacks 4 Comments
In 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.” 🙂