|
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.
|
|
|
|
|
A company I once worked for wanted to outsource a project to a team in Romania.
So, three managers (also the owners of the company) get on a flight to meet the team and discuss the project for three whole days.
When they get back, one of them asks me "can you make an estimation for the project?"
So obviously I ask if the remote team shouldn't make an estimation since they would be building it.
They did make an estimation, but my manager didn't trust it because it was only one or two months away, which they were never going to make, and now he had more confidence in my estimations.
So I aks him how many developers there were on the project.
He didn't know 
I asked him what the hell they talked about if they didn't talk about (believable) estimates and size of the team.
He answered something like "other things, but not that."
So I asked him how the hell he expected me to plan something I don't know anything about.
His reply was "I know it's just guess work, so just guess"
So I "guessed" their original estimate would be accurate, but he wanted another guess 
I think I answered something like "In that case I guess they'll have a hundred developers so they'll be done by tomorrow", but that wasn't the guess he wanted to hear either
It was hands down one of the weirdest conversations I've ever had 
Ultimately, the only correct guess, and maybe you've already guessed it, was "never"
I left the company a year later and another year later they abandoned the project and lost the customer.
|
|
|
|
|
You calculate / compile "function points" and using a "gearing factor" (per language), calculate total man-hours based on historical output per FP (one needs in-house FP stats or an industry estimate). That's the number management gets. How many people they budget is then their problem.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
Yeah, but this wasn't about hours, but when we could deliver to the customer.
|
|
|
|
|
Ah, yes. The old outsource because you're not smart enough to understand the underlying problems.
|
|
|
|
|
Yup, I sent a "no" to my boss yesterday. Again.
If he wants me to produce "CSV files", I'm going to produce proper "CSV files", e.g. ones which Excel recognizes as "CSV" as it's the de facto Standard for "CSV".
He, of course, replied that I should use vertical bars rather than commas because the whack-jobs downstream are using a tool which can't read CSV! In fairness, Microsoft's BCP utility can't read CSV either, but these people are supposed to be developers. And so it goes around again.
Some uber-whack-job up above must have read a blog post about how good this tool is and dictated that everyone across the enterprise needs to stop using what works and switch to this one. piece of crap. Hey, it's expensive, it must be good! 
And, yeah, the same uber-whack-jobs up above have also dictated that everyone needs to use "Scrum" even though every word out of their mouths proves that they have not the first clue what "Scrum" is. 
|
|
|
|
|
You make the "value" of the delimiter an option; reading and writing.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
|
PIEBALDconsult wrote: e.g. ones which Excel recognizes as "CSV" as it's the de facto Standard for "CSV".
That can bring problems... I am in the CSV world at the moment too, and it is a pity because German Excel wants "," for decimal separation, but c++ wants "." for decimal separator.
Having a:
Line 1_1; Line 1_2;
2 empty
Line 3_1; Line 3_2; Line 3_3; Line 3_4;
Line 4_1; Line 4_2; Line 4_3; Line 4_4;
Line x_1; Line x_2; Line x_3; Line x_4;
Opening in Excel to edit something and saving it, then opening with another text editor then you have:
Line 1_1; Line 1_2;;;
;;;;
Line 3_1; Line 3_2; Line 3_3; Line 3_4;
Line 4_1; Line 4_2; Line 4_3; Line 4_4;
Line x_1; Line x_2; Line x_3; Line x_4; Note the additional ";" in lines 1 and 2
And yes... I know, but that's the csv I get from customers... First line is variable and can be less or more than the data part (at least data is a "rectangle")
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.
|
|
|
|
|
Nelek wrote: but that's the csv I get from customers
Glad I'm not the only one! I have one customer's csv import that looks like this:
"1201,05-41-2100-AP,12033.32,07-01-2020,07-31-2020"
Yes, each line is encapsulated in double quotes not to mention the blank lines and subotals/totals spread throughout. This is what they give me, and if I can possibly make things work, I handle it...in this case checking each line for a 34 at the beginning and ending, except where matching pairs occur without a comma, etc. 
After 20 years of dealing with imports, nothing surprises me anymore! It has resulted in some highly customizable options bloat.
One gripe I have about working with .csv files is the fact that Excel will automatically strip leading 0s simply by opening the file, even without saving. 
"Go forth into the source" - Neal Morse
|
|
|
|
|
Bah! That's nothing. How about a "CSV" file which is actually multiple tables of data interleaved? Each line begins with the name of the table it belongs to.
Something like this:
Teacher,Name,Subject,Room
Student,Name,Grade
Class,Name,Teacher,Room,Limit,Enrollment
Teacher,John Smith,Logic,42
Student,Jane Doe,12
Student,John Doe,12
Class,Advanced Logic,John Smith,42,20,Jane Doe|John Doe
|
|
|
|
|
At my last job the vendor and I had to transfer data between two different databases. This was at the height of the XML solves everything craze. When my boss, who was also the company owner, came to us and said to use XML we both looked at him and said no, we've already solved this issue with CSV files which are far easier to read and write.
|
|
|
|
|
Best to do it without writing it to disk at all though, read from one database and write to the other.
CSV is evil. Particularly in the absence of a standard. I try to avoid it.
My boss was on a JSON kick for a while, he'd read a blog post. It seems that he is incapable saying "no".
|
|
|
|
|
Is there a solution to this? Seems this is the case everywhere (maybe almost!) and don't see getting it changed.
Think, it's just live with the reaction for saying No.
And the best option probably would be to provide best guesstimate and take whatever comes on the way as much possible.
|
|
|
|
|
I often work with people from other cultures (programmers, customers, etc) where NO is forbidden. It makes life more polite and unnecessarily difficult. Even if I ask something as simple as "Do you understand?" and the heads politely nod 'yes' regardless of whether they followed me or not. 
|
|
|
|
|
SteakhouseLuke wrote: I often work with people from other cultures (programmers, customers, etc) where NO is forbidden.
I thought the same thing when I read that a dev actually said no to someone.
Most places there is no possible way to say no. They want an estimate and you give them one.
Completely meaningless, but very polite.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
