Two software lessons learned
1. When you make a change, tell somebody about it. Don't just make the change willy-nilly without telling anyone ("While I'm here, I might as well fix this..."). IM your manager, send a note to the mailing list, or file a bug so QA is aware. Someone may raise an objection you hadn't considered.
2. Never throw an exception without a message (throw new Exception()) - put some message inside. Even if the stack trace is logged. Otherwise it can be harder for someone else to debug.
posted by Jonathan @ 1/04/2007 09:28:00 a.m.
2 comments
2 Comments:
I passed your "words of wisdom" on.
This was the reply to it:
I made blunder number one once while working for one client. Actually, my programming partner did too.
My programming partner made a change to the code without commenting it. I discovered the change and removed it thinking I had made a mistake.
Then I was told by the team leader that the change was authorized after the program was up and running.
Never heard from that client again.
Hi Anon - Glad to hear that this principle is validated in the experience of others. A simple rule, and one learned the hard way.
Post a Comment
<< Home