|
RedDk wrote: Try sending them snail mail (us postal) insured with signature required delivery That is both costly and time consuming.
I'd rather hit them "in kind".
In the spirit of your methodology, I once looked up the online presence (it was a small educational institution and HR spammed people to get possible suckers students). Well, as it turned out, they had their top staff and board members on the site, complete with an email contact address - well, I can send out a few hundred angry emails to the bunch of them as easy as to the HR directory - and I did.
There was a lot of displeasure heaped upon the HR director (per his unhappy "apology" - for bothering me). When the sh*t flows uphill, as in this case, the effects are quite gratifying.
Ravings en masse^ |
---|
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
W∴ Balboos, GHB wrote: and I did Often contemplated here.
I once was subpoenaed by a court south of here because I ended up on a list of names of people who were seeking justice in the state for having been wronged by a small business that "took the money and ran". I wasn't on the list for the obvious reason, like contacting State's attorney and BBB etc and complaining, but for dialing up on my land line the actual phone number obtained by going online and seeing who's who on the products (the product I never received, having it ordered through US postal and magazine advertisement) website legal page.
I talked to the head honcho's attorney's secretary, who had a name and, under the guise of seeking legal aid from her boss, began asking particulars about where I might find the office, send more particulars, etc … long story short the story I gave the class-action attorney who was representing the wronged listed sat there at our first meeting the day of the trial trying to think of ways that my testimony could possibly have added to the vigor of his prosecution of that boss … and guess he wasn't satisfied with what I said under oath to the jury of 12 because he never contacted me again to let me know how the trial turned out.
Sound like a nightmare? Long since settled for having done due diligence giving up my $100.00 for a product I never received chalking the whole thing up to experience.
|
|
|
|
|
If you cut down a talking tree, would it dialogue?
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I'd imagine it wood not leave it alone, and bark orders to try and get to the root of the problem. But the converse might be true, and it would fall silent.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
The tree felt pine until it had its trunkate. Now it's more of a shadbush.
|
|
|
|
|
That ent funny!
-- Treebeard
I ought to hit you one!
-- The Whomping Willow
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Is that a sapling tree wit? Perhaps an attempt to branch out but you arboreal out of us, this time! Ultimately, some part of this will end up board.
Ravings en masse^ |
---|
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Ash to Ashes.
I'd rather be phishing!
|
|
|
|
|
The thought of it shivers me timbers!
|
|
|
|
|
I was reminded of this recent event reading Kent's post 5 Project Management Skills Every Developer Should Have[^]
My coworker (I'll use "C" for their name) and I were recently asked by the project manager (for context, he was a very new hire, but that doesn't imply he was new to the field of project management) assigned to our project, "Can you and C put due dates on all of the tasks for this project?"
My one line answer. "No"
The silence was deafening.
After the pregnant silence gave birth, the obvious question "Why not???" was asked.
Well, because:
1. Our daily activities include a variety of other unpredictable tasks that are constantly shifting in priority (aside - such is the life in a small company. Isn't that the definition of Agile? )
2. We are working with undocumented verbal specifications where new information is provided every week in the weekly meeting with the client and often previous requirements change slightly. (aside - we're an Agile team, right?)
3. The nature of the work requires interfacing with third party API's that are finicky and difficult to map their data responses into something we understand how to map to our fields. (aside - everyone is Agile nowadays, right?)
4. Your own (the client's) dataset doesn't have all the information we need and we're waiting for you to update your datasets. (aside - are THEY Agile???)
5. To put a due date on something, yes, we can estimate the number of hours, on average, per day that we can work on the project, but a due date means figuring out how many hours the task will take, and we're dealing with some unknowns that make that impossible at the moment. (Agile!) Once we have removed those unknowns, it may become possible to predict the hours.
Of course, the senior project manager started off the whole conversation with the typical Dilbert-esque management speak: "I am here to facilitate -- if you need something from the client, let me know and I'll make it happen." I've been around the block enough times to know what utter BS that is.
So the manager decided that what his male ego needed was a daily 30 minute conference call with moi and C to review, each and every day (except weekends) the status of each ticket. Riiiight. So we complained to our direct manager, who "managed" - managed to get that stopped. I mean really, the guy can just look at the ticket to see the status, right?
The irony is that this project manager went from being a bull in a China shop to a mouse - no facilitation, no responses to our emails when we actually need some information from the client that he could "facilitate", in fact, no communication at all except an hour before the scheduled weekly meetings "Are you guys ready?"
It's amazing, the Power of No (apologies to Eckhart Tolle)
|
|
|
|
|
For a moment there I thought I was the 'C' in this tale of woe!
I have had almost identical experiences over the last few weeks, so I feel your pain.
HoweverQuote: (aside - everyone is Agile nowadays, right?) No.
One size does not fit all.
|
|
|
|
|
CHill60 wrote: One size does not fit all. Tell that to the airplane sits
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
I love that word.
We live and work in a transient resort town.
Yesterday a fresh (they get off the greyhound daily) 1/2 wit was rolling a trash bin from the local thrift store past our shop.
On the way back it stopped rolling right in front of our screen door. (ruh-row).
"Hi, I found a google pixel phone under the chairlifts (skiing) and want to borrow a computer to remove the password. Do you have one?"
No. - your not virus infecting one of my pcs I thought.
The silence was also deafening.
"I'm helping W!" - (the thrift shop owner).
I just stared him down.
He went on to enumerate all the reasons why I should do this for him and when I seemed unconvinced, he left.
But I tell you, from project managers to street people (indistinguishable at times)
one way to turn their disdain for types like you to respect, is the good old , NO! - at all probable costs.
|
|
|
|
|
Ron Anders wrote: Hi, I found a google pixel phone under the chairlifts (skiing) and want to borrow a computer to remove the password.
Sheesh.
Security (yours) reasons aside, for starters, the phone isn't his to remove the password from. That should've shut him up right there and then.
|
|
|
|
|
The best project manager I worked with used to take my estimates and treble them - the estimates were then generally accurate.
A decent project manager will ask for an estimate knowing that it's really a bit of a guess and communicate that when asking the question.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
The Scotty principle - always multiply your estimates by a factor of four. How else can you maintain your reputation as a miracle worker?
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
I was told one a little different: "double the number and increase the units".
Two days becomes four weeks.
|
|
|
|
|
Never, ever, met one like that....
|
|
|
|
|
I have come across a few project managers who are like that, project managers who want to help the people they work with are not that rare.
I sometimes wonder if the contempt some devs feel for some project managers is what is partly responsible for the occasional problems between project managers and devs.
I have generally found that if as a dev I take the time to explain the complexity and issues involved then most project managers are quite grateful, understanding and do their best to support me as a dev.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
GuyThiebaut wrote: if as a dev I take the time to explain the complexity and issues involved then most project managers are quite grateful, understanding and do their best to support me as a dev.
This has been hit and miss for me in the past. Some PMs really do care about this, others don't. If you don't make them look good, they couldn't care less about your problems. Often times promises are made there are discussions with management / clients that happen without consulting the delivery team, and then they don't want to listen to anything that makes them look bad.
In my experience, some are little more than task admins. They come with a list of tasks asking "Is task x done yet?" and move on. But I have had those that really care about enabling the delivery team, and those are to be treasured.
|
|
|
|
|
I use pi as a multiplier ... it sounds much more scientific when I explain how I adjusted the estimate and it gives even more wiggle room.
|
|
|
|
|
What a pity! You should have come up with some due dates.
"I love deadlines. I like the whooshing sound they make as they fly by" DNA
Mircea
|
|
|
|
|
Marc Clifton wrote: . We are working with undocumented verbal specifications where new information is provided every week in the weekly meeting with the client and often previous requirements change slightly. (aside - we're an Agile team, right?)
This is really the core problem, right?
Plus, that may be what some company or many companies think Agile is (running around with no idea what your doing and having your tasks change and be re-prioritized constantly) but it is not. But, that's a much longer story.
Maybe you should tell C that when he documents the verbal specs and keeps them in change control so you can view the changes over time, then you would be able to give him better estimates.
Software can be extremely easy when you know what your building.
Alas, we rarely get to know what we are building.
|
|
|
|
|
I work in an agile environment and we don't have specifications but we do have user stories.
I am not completely sold on user stories, as I like to know exactly what is required of me.
However they do have the advantage that they help specify what the user wants to do, why they want to do it and what outcome they want - which leaves a certain amount of creativity to the developer to fill in the rest or chat with the person who write the user story.
There are places where user stories are probably not suitable such as medical devices/equipment and avionics.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
GuyThiebaut wrote: I work in an agile environment and we don't have specifications but we do have user stories.
Yes, I think User Stories are good too. They are a balance that the engineering team must understand.
They help define what the user wants to a certain level and are very good.
The dev team or single dev takes the shot and makes it work as best they understand.
The product team tries it out (so difficult to get them to really do this) since they should know best what needs to change. If they can't describe that to the dev then the dev's shot at it must be considered final.
however, everyone has to understand that when a dev is getting a thing to work and there are requirements gaps then the dev is the final answer while development is actively occurring (in the sprint). Sure later when everyone reviews it that could mean another iteration to fix it the way they think it should be. That's fine.
But this is also why Agile may not work on teams where people really eventually only attempting to escape blame and point the finger at the person who is ultimately responsible and must take the fall.
Agile requires that there is an actual team who cares for the final product and the other members. If you don't have that -- and a LOT of places don't -- then Agile is as bound to fail as all other Process Methdologies...or more so.
Sounds like the way your team does it works well. Our team does this too and we like Agile fairly well, though there are other challenges too.
|
|
|
|