Documentation: How thorough are you with it?
-
Not code documentation so much but the documentation involved with requests/mods/enhancements. Stuff like who made the request, dates and times, reason for the change or mod, that kind of stuff. Documentation that you would use for audit purposes and for catching people in lies. I am glad that I archive my e-mails and keep files for EVERY project that I work on; it has saved my ass on numerous occasions. I have been in a back and forth, he said - she said, ordeal as of late, where a project manager has said that they notified us of some enhancements/changes that needed to be made and we show no documentation or proof that this meeting ever took place. Now, the powers that be want to know who dropped the ball.
-- ** You don't hire a handyman to build a house, you hire a carpenter. ** Jack of all trades and master of none.
-
Ian Shlasko wrote:
That's rare.
Sarcasm? Can't tell. I have always worked in shops that have women on the teams. Some of the best developers I have worked with are women. My immediate boss is a woman and I have learned a lifetime of stuff from her.
-- ** You don't hire a handyman to build a house, you hire a carpenter. ** Jack of all trades and master of none.
Wow, really? My entire career, I've only worked with two female developers... Well, they were on the server team, while I was working on the client, but still... There were a couple women in QA too, but no other programmers.
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels) -
Wow, really? My entire career, I've only worked with two female developers... Well, they were on the server team, while I was working on the client, but still... There were a couple women in QA too, but no other programmers.
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels)Ian Shlasko wrote:
Wow, really?
Yes. and some are very easy on the eyes as well. ;)
-- ** You don't hire a handyman to build a house, you hire a carpenter. ** Jack of all trades and master of none.
-
Not code documentation so much but the documentation involved with requests/mods/enhancements. Stuff like who made the request, dates and times, reason for the change or mod, that kind of stuff. Documentation that you would use for audit purposes and for catching people in lies. I am glad that I archive my e-mails and keep files for EVERY project that I work on; it has saved my ass on numerous occasions. I have been in a back and forth, he said - she said, ordeal as of late, where a project manager has said that they notified us of some enhancements/changes that needed to be made and we show no documentation or proof that this meeting ever took place. Now, the powers that be want to know who dropped the ball.
-- ** You don't hire a handyman to build a house, you hire a carpenter. ** Jack of all trades and master of none.
That's what BA's are for.
I wasn't, now I am, then I won't be anymore.
-
Actually that is a very good practice ! At least they focus on a solution instead of on the problem. :-D
V.
It is also polical correctness. Basically there is no reward for high quality work and no punishment for screwing up, because nobody should be "pointing fingers" no matter what.
-
Not code documentation so much but the documentation involved with requests/mods/enhancements. Stuff like who made the request, dates and times, reason for the change or mod, that kind of stuff. Documentation that you would use for audit purposes and for catching people in lies. I am glad that I archive my e-mails and keep files for EVERY project that I work on; it has saved my ass on numerous occasions. I have been in a back and forth, he said - she said, ordeal as of late, where a project manager has said that they notified us of some enhancements/changes that needed to be made and we show no documentation or proof that this meeting ever took place. Now, the powers that be want to know who dropped the ball.
-- ** You don't hire a handyman to build a house, you hire a carpenter. ** Jack of all trades and master of none.
FRD before coding starts (I call it a Solutions Requirement Document, although it is heavy on Function and light on Form), possibly augmented by Use Cases. Solutions Control Document after the project is implemented - describes the platform, deployment type, etc. Additonally, we are bound by Sarbanes-Oxley (SOX) auditing, and every change/implementation to a production server requires a Change Request to be created. This typically includes tasks for: . Request to Proceed (completed by customer) . Testing Completed (completed by customer) . Deployment to Production (documented by IT, approved by Change Management) . Post-Release Review (completed by customer)
-
Not code documentation so much but the documentation involved with requests/mods/enhancements. Stuff like who made the request, dates and times, reason for the change or mod, that kind of stuff. Documentation that you would use for audit purposes and for catching people in lies. I am glad that I archive my e-mails and keep files for EVERY project that I work on; it has saved my ass on numerous occasions. I have been in a back and forth, he said - she said, ordeal as of late, where a project manager has said that they notified us of some enhancements/changes that needed to be made and we show no documentation or proof that this meeting ever took place. Now, the powers that be want to know who dropped the ball.
-- ** You don't hire a handyman to build a house, you hire a carpenter. ** Jack of all trades and master of none.
-
Fortunately this no longer impinges on my life. I say fortunately because I was probably the worlds worst. Code documentation - immaculate. Any other form of documentation - abysmal. I would forever be in the situation of meeting 'fred' (who submitted a feature request a couple of days ago), in the lift or canteen, or wherever, and during the conversation we would agree some change to it. That remained in my head, it got done, but wouldn't be documented until the completion stage. Personally I blame him, he should have submitted a change to the change request.
Henry Minute Do not read medical books! You could die of a misprint. - Mark Twain Girl: (staring) "Why do you need an icy cucumber?" “I want to report a fraud. The government is lying to us all.” I wouldn't let CG touch my Abacus! When you're wrestling a gorilla, you don't stop when you're tired, you stop when the gorilla is.
Henry Minute wrote:
I would forever be in the situation of meeting 'fred' (who submitted a feature request a couple of days ago), in the lift or canteen, or wherever, and during the conversation we would agree some change to it. That remained in my head, it got done, but wouldn't be documented until the completion stage.
The difficulty, from the POV of proj mgrs, requirements writers, and others who work with developers, is that often the canteen-line conversation was stated as "is this possible," "how difficult would it be," or "how long would this take" and wasn't meant to actually be done. With that info, the non-dev has in mind conversations they need to have with the customer, then at some point the change would be put into a "real" request. Instead, *poof* the change has been made without anyone expecting it, and now there's much scrambling to be done. I'm not saying this is always the case, but I see it often enough that I try to be explicit - "I am NOT asking you to make a change, I'm just asking for information here." If you're having this sort of situation come up repeatedly in your org, perhaps a "do you actually want this change or are you just asking for information?" type question would help avoid it. Or not, depending on the personalities involved :| -S
-
It is also polical correctness. Basically there is no reward for high quality work and no punishment for screwing up, because nobody should be "pointing fingers" no matter what.
-
Slacker007 wrote:
Now, the powers that be want to know who dropped the ball.
That's good. In my company, the power that be never want to know who dropped the ball. All they ever ask is who can fix it and how long will it take. By not asking, I think they assume it is your fault (your name is the de-fault value). :)
"I think they assume it is your fault" It could also mean they really don't care. Or maybe they know that all finding out will accomplish is to create fodder for office politics and create a CYA work culture, both of which are counterproductive to making money.
patbob
-
Henry Minute wrote:
I would forever be in the situation of meeting 'fred' (who submitted a feature request a couple of days ago), in the lift or canteen, or wherever, and during the conversation we would agree some change to it. That remained in my head, it got done, but wouldn't be documented until the completion stage.
The difficulty, from the POV of proj mgrs, requirements writers, and others who work with developers, is that often the canteen-line conversation was stated as "is this possible," "how difficult would it be," or "how long would this take" and wasn't meant to actually be done. With that info, the non-dev has in mind conversations they need to have with the customer, then at some point the change would be put into a "real" request. Instead, *poof* the change has been made without anyone expecting it, and now there's much scrambling to be done. I'm not saying this is always the case, but I see it often enough that I try to be explicit - "I am NOT asking you to make a change, I'm just asking for information here." If you're having this sort of situation come up repeatedly in your org, perhaps a "do you actually want this change or are you just asking for information?" type question would help avoid it. Or not, depending on the personalities involved :| -S
"I am NOT asking you to make a change, I'm just asking for information here." As a developer asked those kinds of what if questions, I learned to ask the correllary question at the end of the conversation.. "so, do you want me to go ahead and make that change?". They should teach that to new developers in developer school :)
patbob
-
Not code documentation so much but the documentation involved with requests/mods/enhancements. Stuff like who made the request, dates and times, reason for the change or mod, that kind of stuff. Documentation that you would use for audit purposes and for catching people in lies. I am glad that I archive my e-mails and keep files for EVERY project that I work on; it has saved my ass on numerous occasions. I have been in a back and forth, he said - she said, ordeal as of late, where a project manager has said that they notified us of some enhancements/changes that needed to be made and we show no documentation or proof that this meeting ever took place. Now, the powers that be want to know who dropped the ball.
-- ** You don't hire a handyman to build a house, you hire a carpenter. ** Jack of all trades and master of none.
That's a good point. I've almost gotten into an actual fight in a meeting with a business person that could contradict himself at the rate of about 3 times every 10 minutes. And swear up and down with a straight face that's not what he told you 5 minutes ago. During meetings or phone calls, take notes. Then write up an email afterward with what was agreed on and send it out to everyone involved to get "official" approval. "Here are my notes from the meeting. Could you confirm that this is what you would like us to do?" Or something to that effect. Make it explicit and complete, double check it for vague or misleading language. Even in long email strings it may be necessary toward the end to summarize into a more concise form what you've been hashing out and get a final approval on what is actually going to be done. You can be tossing around options, and it can get confusing about what you're actually going to do or not do. Especially when you have a client that waffles like IHOP. If you're billing time, it's hard for the client to argue against hours after changing their mind about what they agreed to in an email. And it can save you a lot of hassle and hair pulling down the road.
-
"I am NOT asking you to make a change, I'm just asking for information here." As a developer asked those kinds of what if questions, I learned to ask the correllary question at the end of the conversation.. "so, do you want me to go ahead and make that change?". They should teach that to new developers in developer school :)
patbob
Yea, that's a "accurate communication is both parties' responsibility" thing. It would be great if we all would do it (I'll admit that I don't always do it either). Otherwise one party or the other (or both) is making an assumption... and we all know what that does.
