The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
1. The lounge is for the CodeProject community to discuss things of interest to the community, and as a place for the whole community to participate. It is, first and foremost, a respectful meeting and discussion area for those wishing to discuss the life of a Software developer.
The #1 rule is: Be respectful of others, of the site, and of the community as a whole.
2. Technical discussions are welcome, but if you need specific programming question answered please use Quick Answers[^], or to discussion your programming problem in depth use the programming forums[^]. We encourage technical discussion, but this is a general discussion forum, not a programming Q&A forum. Posts will be moved or deleted if they fit better elsewhere.
4. No politics (including enviro-politics[^]), no sex, no religion. This is a community for software development. There are plenty of other sites that are far more appropriate for these discussions.
5. Nothing Not Safe For Work, nothing you would not want your wife/husband, your girlfriend/boyfriend, your mother or your kid sister seeing on your screen.
6. Any personal attacks, any spam, any advertising, any trolling, or any abuse of the rules will result in your account being removed.
7. Not everyone's first language is English. Be understanding.
Please respect the community and respect each other. We are of many cultures so remember that. Don't assume others understand you are joking, don't belittle anyone for taking offense or being thin skinned.
We are a community for software developers. Leave the egos at the door.
Maybe more. I gave NewEgg some feedback and got an obvious robo-reply, complete with first name and last initial. They asked me to evaluate the reply . . .
Yesterday, I got another email - asking if I'd like to give a testimonial post to their site because I was such a satisfied customer (after my initial quite negative feedback).
So today's joy from NewEgg I should take care of (buy) stuff I forgot in my cart or they may have to remove it. The stuff in my cart? A pair of video games - sh*t I wouldn't use if it arrived free on my doorstep. Wouldn't be interested enough to look at, let alone put in my cart.
So I'm pretty much ready to cancel all email from them to me - I mean really, do you think I would go to NewEgg to buy vitamins (yes, they really sent that to me!)? Their new Chinese owners seem to think business is best run by selling in the same spirit as sending SPAM.
Actually, the more I think about it, the more 85% seems like an understatement.
Personally, if I get spam from someone with whom I do business, I update my profile on their site and remove any permission to send me messages (aka spam). If I subsequently get any spam from them, they lose my business.
Companies with whom I do not do business are removed from my list of potential suppliers.
If everyone behaved that way, email might return to being a useful tool once more.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
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
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.
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)
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.
. 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.”
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.
Last Visit: 5-Aug-20 15:04 Last Update: 5-Aug-20 15:04