The Power of No
-
The Scotty principle - always multiply your estimates by a factor of four. How else can you maintain your reputation as a miracle worker? :-D
"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.
-
Quote:
...I was asked to move a deadline on a 3 month project, up a month...
I've been asked that recently in a similar timeline. I said "OK" :laugh: Then I said "Which bits do you want me to leave out?" I got some funny looks at that point, and the "nothing should be left out" response. I then wasted another 15 minutes of my life explaining that the work they required would take 4 months, so they could either have all of the work after 4 months or some of the work after 3 months. Now they've got me in overly frequent, regular meetings to review how we are against plan. The irony that these meetings are eating into my available dev time is completely lost on them :doh:
And people wonder where Scott Adams gets his material. The man must have worked in development.
Real programmers use butterflies
-
honey the codewitch wrote:
I realized part of my job was to protect management from themselves.
Yeah, so often the sad truth. Especially when the manager explicitly says "my boss is breathing down MY neck." Oi. Talk about roll reversal, which it should be the manager's job to protect you!
Latest Articles:
Proxy class for TypeScript/Intellisense DOM manipulationI agree. It was one of things I really didn't like about the field.
Real programmers use butterflies
-
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 :wtf: 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" :wtf: So I "guessed" their original estimate would be accurate, but he wanted another guess :laugh: 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 :laugh: 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" :sigh: I left the company a year later and another year later they abandoned the project and lost the customer.
Best, Sander sanderrossel.com Migrating Applications to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
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
-
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! :sigh: 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. :doh:
-
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! :sigh: 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. :doh:
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.
-
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.
-
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? :laugh: ) 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 reall
I had to jump in a project that was already way behind schedule. My first week there was almost only letting people explain me what it should be done and where we were. I tried to analyze what the previous guy was doing and then I called my boss, because repairing that mess would take me more time than starting over again. He let me do it. 2 weeks later, I was already moving the machine in semi-automatic. Then an appointment with the customer was done. When they came the project manager was trying to explain things where I was internally hitting my head against the desk. Then the customer started asking for things and the project manager would open his mouth. At some moment I got tired and said... NO. All quiet, staring at me... Customer: Pardon? What do you mean? Me: Because blah blah blah Next day he was speaking with me using "Du" instead of "Sie" (the formal form in Germany) the other team members were :omg: :omg: and asked me if he knew him from before... ME: No, I met him yesterday, why? They: Because the project manager had been working for him as extern for 4 or 5 years and was still being spoken with "Sie" I suppose I got his respect exactly when I said "No" and then I gave him technical reasons to support my "No" some of them even protecting the machine or the ergonomy of the future operators of his company. I gave him even an alternative (that he payed extra, because was against was written in the contract) So yes, learning when to say "No", being confident enough to say it and good enough to counter with objective arguments... is one of the worthiest thing that comes with experience
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 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? :laugh: ) 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 reall
A long time ago I read somewhere that when writing software it takes 95% of the forecast time to do 95% of the work and another 95% of the forecast time to do the remaining 5% work. Whenever the PM insists for estimates on task duration I make a generous estimate and double it.
-
Quote:
...I was asked to move a deadline on a 3 month project, up a month...
I've been asked that recently in a similar timeline. I said "OK" :laugh: Then I said "Which bits do you want me to leave out?" I got some funny looks at that point, and the "nothing should be left out" response. I then wasted another 15 minutes of my life explaining that the work they required would take 4 months, so they could either have all of the work after 4 months or some of the work after 3 months. Now they've got me in overly frequent, regular meetings to review how we are against plan. The irony that these meetings are eating into my available dev time is completely lost on them :doh:
-
I had to jump in a project that was already way behind schedule. My first week there was almost only letting people explain me what it should be done and where we were. I tried to analyze what the previous guy was doing and then I called my boss, because repairing that mess would take me more time than starting over again. He let me do it. 2 weeks later, I was already moving the machine in semi-automatic. Then an appointment with the customer was done. When they came the project manager was trying to explain things where I was internally hitting my head against the desk. Then the customer started asking for things and the project manager would open his mouth. At some moment I got tired and said... NO. All quiet, staring at me... Customer: Pardon? What do you mean? Me: Because blah blah blah Next day he was speaking with me using "Du" instead of "Sie" (the formal form in Germany) the other team members were :omg: :omg: and asked me if he knew him from before... ME: No, I met him yesterday, why? They: Because the project manager had been working for him as extern for 4 or 5 years and was still being spoken with "Sie" I suppose I got his respect exactly when I said "No" and then I gave him technical reasons to support my "No" some of them even protecting the machine or the ergonomy of the future operators of his company. I gave him even an alternative (that he payed extra, because was against was written in the contract) So yes, learning when to say "No", being confident enough to say it and good enough to counter with objective arguments... is one of the worthiest thing that comes with experience
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:
So yes, learning when to say "No", being confident enough to say it and good enough to counter with objective arguments... is one of the worthiest thing that comes with experience
Very :cool:
Latest Articles:
Proxy class for TypeScript/Intellisense DOM manipulation -
honey the codewitch wrote:
I realized part of my job was to protect management from themselves.
Yeah, so often the sad truth. Especially when the manager explicitly says "my boss is breathing down MY neck." Oi. Talk about roll reversal, which it should be the manager's job to protect you!
Latest Articles:
Proxy class for TypeScript/Intellisense DOM manipulationMarc Clifton wrote:
it should be the manager's job to protect you!
Do they exist?
For your read/comments: Beginner’s Guide to understand Kafka Beginners Quick Start to Learn React.js
-
A long time ago I read somewhere that when writing software it takes 95% of the forecast time to do 95% of the work and another 95% of the forecast time to do the remaining 5% work. Whenever the PM insists for estimates on task duration I make a generous estimate and double it.
Back in the day I did mine with factor 1,5 if I had a really good project description and I did my own chats with the customers. A 2,5 or even a 3 when I had bad specs or no first hand information. My boss still added a 50% more, so he could bargain with the customer up to 25% down and still have his own buffer.
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.
-
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
Ah, no.
-
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
:laugh: 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. :doh: 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. :confused:
"Go forth into the source" - Neal Morse
-
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. X|
Working with the Japanese can be soooo frustrating. I built an entire solution based on their response only to find out it was completely wrong. We had to send an interpreter to Japan to get straight answers.
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
-
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.
Best, Sander sanderrossel.com Migrating Applications to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
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? :laugh: ) 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 reall
-
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
Never, ever, met one like that.... :sigh:
-
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? :laugh: ) 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 reall
I've always been a fan of saying "no" when it's needed. As long as it's done the proper way, I find it only helps with planning and actually improves your professional image in the eye of your counterpart. Well, managers are often an exception to that rule, alas! :laugh: A few years ago I had a particularly funny (though it was NOT funny for me at the time!) eexperience: a big client's PM called me to discuss the schedule of a rather big project. She sent me the whole planning and we went through all the deadlines and discussed in detail all activities. In the end, it was a demanding schedule, but not impossible. I was positively surprised, and agreed that it was doable. That's when I commented on a date for a meeting: I was not available on that specific day. She told me to ignore the dates on the schedule... I said "what?". She said yeah of course the schedule was about the time it would take to complete the project, but the date on the schedule were all off: the project would start the next day instead of the next month... Let's just say that I answered with something more... articulate than a simple "no" :laugh:
In theory, there is no difference between theory and practice, but not in practice. - Anonymous A computer is a stupid machine with the ability to do incredibly smart things, while computer programmers are smart people with the ability to do incredibly stupid things. They are, in short, a perfect match. - B. Bryson
