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.