17 ms·

An important aspect of being a professional software engineer is having the backbone to sometimes say things like: - “I don’t know yet enough about the problem

• taneq 8y ago
  100% this. It's not your job to say something that will make your client happy. It's your job to tell them your honest assessment of the task.
  • chii 8y ago
    Imagine a tradie saying it'd take 1week to finish remodelling your kitchen, and then it turns out they couldn't. As a professional, it's your responsibility to educate the client on the issue - most technical problem could be explained to a layman if the context is set up properly. The problem occurs when the client doesn't want to hear it.
    • moccachino 8y ago
      From around here that's everyone's experience of tradespeople in every non-emergency task. "Sure I can do this in 3 weeks." Then shows up once every two weeks and finishes around the four month mark.
      • watt 8y ago
        I guess he was estimating the effort (billable time). But was not estimating the actual total time until completion which must include all the lead time, waits and dependencies.
        • taneq 8y ago
          This is another part of the whole 'communication with clients' thing. You have to be clear whether you're talking coding time or wall-clock time. To be safe, give both.
      • bigiain 8y ago
        I see exactly the same routine in our game. "Yes we can do that in three weeks. We need the API documentation for _those_ two systems, network access to _those_ resources, and credentials to log in to _those_ services first." 2 months later we're still waiting on critical pieces of those prerequisites, while someone's screaming that the deadline they'd committed to with the customer was 5 weeks ago.
        • taneq 8y ago
          Oh yeah. This is why I'm always very careful about quoting prerequisites for any deliverable. "We can do X in 5 weeks after receipt of Y, Z and W." Then when they say "why don't we have X," I politely inquire after Y, Z and W. The most important part of this process is getting it in writing so that you can slap them with it later.
          • chii 8y ago
            > after receipt of Y, Z and W. the problem comes when you didn't know you need Y, Z or W until the work actually starts.
• Cthulhu_ 8y ago
  The other thing you can always refer back to is that the accuracy of an estimate increases the closer it is to finishing it - that is, it's very inaccurate at the start. This is one of the pillars of the agile way of working - you and your team can give a fairly accurate estimation for what can be finished within a week or two. Not so much for a year. The longer estimations are very much due to changing priorities and a developing environment and understanding of what is being built though, hence the inaccuracy.
• tonyedgecombe 8y ago
  >But when you advocate clearly for your needs as a professional, people are generally reasonable. You should do all this but there will still be times when people are unreasonable, it's just human nature.
  • afarrell 8y ago
    Right, thats why steeling yourself for the possibility of having to deal with unreasonableness is important. If you run into it, the first step to dealing with it is to get someone to explain what they expect clearly, in relevant detail, and non-hyperbolically. This short-circuits the possibility of mere misinterpretation. They might have just been expressing their emotions but not yet grappling with their desires in concrete terms—doing so might bring them back down to earth. Then you can resume jointly problem-solving. If that doesn’t work...I’m actually not sure. But I just started reading the book Crucial Conversations and it claims to have a relevant answer.
• wiz21c 8y ago
  >> and then standing your ground when they pruessure you to lie to them. spot on.
• koonsolo 8y ago
  I once had a manager/CEO who thought you can negotiate the planning, the same as like a price. "The customer always wants to get it earlier, the engineer later". Me saying that only the developer is able to give a realistic planning, was probably received as "developer wants to push the deadline back in his negotiation". In the end, his company went bust because he was selling stuff to customers that could never be delivered on time, or even never at all.
  • afarrell 8y ago
    There is a type of negotiation that can be done: Negotiation about scope. Work doesn’t get compressed. But stakeholders can identify non-essential business-facing features and cut scope. Note well: Automated testing is almost certainly essential. If someone says you are “building an MVP”, then make sure it is an actual MVP. Make sure you have a clear market hypothesis to test and check that it couldn’t be built out of duct tape, Google Forms, Zapier, ITTT, manual processes, and excel-wrangling.
    • drunkpotato 8y ago
      Hah! You just described the start of one of our products so accurately it’s scary! And then we built out the parts that were starting to fail as the product scaled. You can get surprisingly far this way!
    • mgkimsal 8y ago
      Testing will happen. The choice you make is who does the testing and when it happens. Internal people testing earlier is generally preferable to external customers testing 'live', but either way, the testing will happen.
      • afarrell 8y ago
        “We can’t make those UX improvements to our core open-source product because then we’s have to introduce untested code. The current code is tested because users have used it and reported the bugs and we’ve fixed them.” Is a real thing a project lead said to me at a previous employer.
• maxxxxx 8y ago
  I'm on a project right now and I am telling people "I don't know how long it will take because nobody here has ever done anything like this. The only thing I can tell you is that nobody is wasting time and we are solving problems as quickly as we can. Look at the JIRA board and see what we have done and what we are planning to do and make your own estimate". So far I haven't been fired. I also refuse to stop work and start long planning meetings like I have seen in previous projects.
  • arethuza 8y ago
    I once worked for CEO as a Director of Engineering who was convinced that any product feature could be implemented in 2 days - and this was a non-trivial engineering area. That was an entertaining job.
    • mgkimsal 8y ago
      curious about this person's reaction to things not being implemented in 2 days. did he/she think that people were just dragging their feet? or not as smart? or sabotaging things to make him/her look bad?
      • arethuza 8y ago
        He just edited it out from his version of reality! In fact, in all the time I was there (roughly a year including a major new product launch) I don't think anything was ever done in 2 days. Another interesting characteristic he had was to get upset if he thought projects were running too smoothly...
        • maxxxxx 8y ago
          We have a manager who seems to think that the only way to get good performance is to set impossible deadlines. There are no consequences for missing but it’s pretty unpleasant and stressful to have to deal with this.
    • VBprogrammer 8y ago
• koonsolo 8y ago
  > They probably don’t want you to lie, but there is a small chance that they pruessure you to. In my experience, most of the time there was pressure. I remember a funny conversation between my project manager and a colleague: PM: "We need to have X as soon as possible, how long will it take you?" Dev: "Oh that's, easy, I can finish it tomorrow." PM: "Tomorrow??? That's impossible, because it needs a and b, no?" Dev: "Yes you are right... I can probably finish it by next week." PM: "Next week??? That is a long time! It's only a, b, c and d that needs to be done. Does it all take that long?" Dev: "You are right, I can probably finish it sooner. I can get it ready by this Friday." PM: "That is perfect! The customer wanted to put in production on Monday, so we can now confirm. Thanks!" I overheard that story (open office), and it was a real facepalm moment.
  • golergka 8y ago
    > Does it all take that long? That's just a question. Asking questions is OK. If you have such a high need to please other people and such a low self-confidence that you will change your answer simply if someone asks you twice, that's the problem with you, not them. I say it as someone who have been like that and have changed it through therapy. I was a nervous mess and always thought that people around me don't like me, pressure me and in general was very nervous around any interaction where I and other person have some disagreement. But turns out, firmly saying "No" is quite OK, people react well to it, respect you for it and nobody is going to fire you for giving good estimates.
    • afarrell 8y ago
      This is the core of my point. Therapy was helpful for me learning it as well.
    • biql 8y ago
      This is gold. Besides, if someone doesn't react well to your honest estimates, this is probably a red flag and you're better off letting them find someone else. After all, this is supposed to be in everyone's best interests.
    • jshowa3 8y ago
• teddyh 8y ago
  I would recommend this talk regarding professionalism: https://www.youtube.com/watch?v=p0O1VVqRSK0#t=5m20s https://www.youtube.com/watch?v=p0O1VVqRSK0#t=5m20s EDIT: The part about estimates is here: https://www.youtube.com/watch?v=p0O1VVqRSK0#t=36m56s https://www.youtube.com/watch?v=p0O1VVqRSK0#t=36m56s
  • afarrell 8y ago
    I'd replace "they are hired for their knowledge" with "professionals are hired for their judgement". Judgement usually depends upon knowledge, but its the exercise of judgement that is more key to emphasise.
• moring 8y ago
  On the other hand, you can only argue about the estimate if there is even a channel to argue about it. I have seen several cases of (1) people being told about a deadline through various proxies, so there was no point in time where they could even question the imposed deadline, (2) people not being told about the deadline at all until it was missed, so they could not argue against it, (3) people not being told about the task that has a deadline until after that deadline was missed. All involved engineers actually had the backbone to say it was impossible, but no chance to say it. Obviously, projects did not go well at that place.
  • pvorb 8y ago
    At least this saved the engineers quite some amount of time.
• GlennS 8y ago
  Well, this is some good advice. Another nice trick if you're under time pressure is to arrange the project so that you can deliver it in stages that partially meet the requirements, or even deliver something non-functional that people can play with while they wait. This can keep the sales team rolling or customers happy for a while, buying you some time to write the program properly. As a bonus, you might get earlier feedback if you're going in the wrong direction, in which case less time wasted. (Obviously this approach isn't always possible. Many problems won't decompose nicely.)
  • afarrell 8y ago
    this is where it becomes crucial to know why you're building the thing you're building. That way, you can often structure the project in phases according to your engineering judgement of the way those phases are built and the business value they enable. Then you can cut scope by postponing (or not doing) some of the phases. Ideally.
• Aeolun 8y ago
  > But when you advocate clearly for your needs as a professional, people are generally reasonable. This has not been my experience. People want ‘estimates’ at all costs, tell you to not worry about any accuracy, and then a week later tell your manager you committed to x date.
  • afarrell 8y ago
    This is a real thing that happens, but its frequency varies from organisation to organisation.
  • retiredcoder 8y ago
    “Let’s just put some number in those boxes”, next thing you know it is signed on blood...
  • nahname 8y ago
    As long as software is a cost center to your company, it will be treated this way. Trying getting a job at a company where software is a core concern. Ideally with a CEO that is not from a marketing/business background.
    • afarrell 8y ago
      For more on this sort if thing, Patrick McKenzie’s writing is good: - https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/ https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr... - https://www.kalzumeus.com/2014/04/09/what-heartbleed-can-teach-the-oss-community-about-marketing/ https://www.kalzumeus.com/2014/04/09/what-heartbleed-can-tea...
      • kirRoyale 8y ago
        You are right, great posts. Thanks for sharing.
      • SamuelAdams 8y ago
        Thanks for the links! I really wish I read these when I was in my undergrad, they are really good!
• cs02rm0 8y ago
  I find you have to do this, but it can damage professional relationships. Recently I've flat out said no, as gently as I could, to doing some work - porting a software stack to run on Windows. A customer is asking for an estimate to do it, because a project manager who wouldn't be developing or supporting (or even using) the system likes Windows. The sales manager isn't thrilled with me over it. So he's asked the team as a whole to estimate it because I wouldn't. The rest of the guys are frontend devs. I don't have a clue, they're in a worse position but for some reason they're all up for putting a number to it so I look like a bit of a ! I'm a contractor, so I can and would just turn down the work, but it's difficult politically.
  • circlefavshape 8y ago
    This drives me crazy! Dev: "It's a really bad idea, will take an indeterminate amount of time, and be a maintenance nightmare" PM: "Can I just get an estimate?"
    • kthejoker2 8y ago
      I'm a big believer in pushing back on small words doing heavy lifting. "Just" is a big red flag in software delivery.
  • adrianmsmith 8y ago
    Ok cool but if they have to deliver it, they’ll look like fools in the long run when they can’t, and in the end they’ll see you’re right? So it’s a win for your reputation in the long term I think?
    • marcosdumay 8y ago
      That's naive. Nobody will revisit the GP's reputation, and after the novice devs fail to do the work people will just scatter into different projects. They may or may not take a reputation hit, while the PM that insists so much on doing the not viable work will take none of it.
    • werbel 8y ago
• snarf21 8y ago
  I agree with you but like others have said, they want a date they can sell to and in the end it will be your fault. It isn't just software that goes double, look at most custom building projects or government contracts. Most everything takes twice as long and costs twice as much. I read something once that has stuck with me. "We can never give more than a vague guess because we are literally building something that doesn't exist and has never been built before." * I do find it annoying that the sales teams generally drive this. I wonder how they would feel about a response of "We'll get you an estimate of when it will be available as soon as you get us an estimate of when this feature will generate the $1M of revenue to cover the costs of building it. Also, please give us a list of customers that are likely to buy it and your expected contract date so we can track it along with development."
  • Bartweiss 8y ago
    > It isn't just software that goes double, look at most custom building projects or government contracts. Most everything takes twice as long and costs twice as much. There's definitely a correspondence here, but it's a bit indirect. Government and even private contracts are often knowingly lowballed to secure the deal. Rules like "must choose lowest bid" reward entering an unrealistic bid and then inflating costs after work is going. Or, if overruns come with sufficient penalties, doing work at a loss and then charging a fortune to support a fragile and proprietary result. In the metaphor to non-contracted software, developers generally don't correspond to the contractors but to the government. Sometimes blown estimates are simply errors, but other times somebody wanted to secure customers, so they pitched an unrealistic scope and arranged to make the inaccuracy land on the programmers. Where the government ends up with late delivery or runaway costs, programmers end up working crunch time or sacrificing quality. And where the government ends up locked into paying for support, programmers end up locked into maintaining rushed, tech-debt-riddled work. (As for pushing sales for revenue and contract estimates, do it! Some of the most productive teams I've been part of have been ones where sales applied this pressure, but also responded well to the reverse version and kept everyone informed.)
• singingfish 8y ago
  I like to mess with people. "It's 80% done so there's only 80% left to go". "Now' it's 90% done so there's only 90% left to go" etc. Of course my current project is rather higher stakes than usual, so I'm being a little bit more sober than I normally would be. However I am emphasising the need for communication with other stakeholders and identifying and trying to rectify where they are bottlenecks pdq.
• artworx 8y ago
  I highly recommend the book "Software Estimation: Demystifying the Black Art". I work for an outsourcing company and part of my job is to come up with estimates and it helped me deal with clients and managers. The book contains a quiz that we used as part of a training exercise with management and the results were hilarious. Here is an online copy: https://scrumandkanban.co.uk/how-accurate-are-your-estimates/ https://scrumandkanban.co.uk/how-accurate-are-your-estimates... please don't look at the answers, I guarantee you will have fun completing it. For clients, my preferred approach is to show "The Cone of Uncertainty" and ask where they think they are. Since most people have no idea what they want to built I ask if its ok if my estimates are 4x off. That usually gets me a few weeks of peace while a team comes up with a product definition and we start all over again :)
  • afarrell 8y ago
    I started reading that book in 2014, but put it down because it really was about project-level estimation on the order of a few weeks to a few months. At the time, I was really looking for guidance on how to estimate tasks—things on the order of a few hours to a couple days. I’ve gained some experience and confidence at this in the years since, but at the expense of some psychologically painful experiences and a firing. Our industry really calls out for a more basic book aimed at University CS grads (or bootcamp grads or MOOC)-grads on how to estimate tasks.
  • panarky 8y ago
    That quiz has an unintentionally apt question. > Total length of the coastline of the Pacific Ocean Coastlines are fractal. If your measuring stick is 1 km long, you'll get one number. If it's 1 m long, you'll get a much larger result. And if it's 1 cm long, you'll get an even larger result. https://en.wikipedia.org/wiki/Coastline_paradox https://en.wikipedia.org/wiki/Coastline_paradox The actual length of a coastline is infinite when measured with an infinitesimally small measuring stick. Software development effort also increases, unbounded, as discovery proceeds and the precision of requirements increases.
    • polygotdomain 8y ago
• JustSomeNobody 8y ago
  > “I don’t know yet enough about the problem to give you even a rough estimate. If you’d like, I can take a day to dig into it and then report back.” This is my default. Even when I am fairly confident I know what the code does, I want to double check. And it isn't just so I don't short change myself on time. If I tell them X days and deliver on 0.X days several times, they'll start thinking I overestimate everything and cut me off at the knees. It pays to get as accurate as possible.
  • afarrell 8y ago
    Its a good default.
• agumonkey 8y ago
  I wish school taught me how to do your first point. People talk about project management, gantt diagrams and all that but you have no idea how to estimate even grossly the complexity of a thing.
  • afarrell 8y ago
    The lack of a good “intro to task and small project management” MOOC or book is a serious problem for our industry’s ability to onboard junior engineers. I wish I knew how to write one, but TBH I don’t know any principles myself except one. Lots of people say “just do it and multiply by 3” without appreciating that The important part of estimating tasks is coming up with the task breakdown and identifying the risks.
    • mntmoss 8y ago
      The best you can do in most scenarios is to research comparable projects and calibrate against them. "They shipped in six months, therefore we can ship in six months."
      • afarrell 8y ago
        Have you ever done this and had it turn out successfully? Because my intuition is screaming at me that this would be disastrous. For one, it skips the step where you break down the tasks. For another, it seems likely to ignore a bunch of variables in the search for something similar enough.
      • agumonkey 8y ago
        Both the mentionned idea are natural, but it's ultra sad that we can only live by experiment like craftsmen for previous eras. Not that I mind craftmanship but at least school should write it in bold letters so you're not seeking a mathematical model.
• taherchhabra 8y ago
  once my CEO asked: "can we add more developers and finish the project faster". I used this famous quote "9 mothers cannot deliver a baby in one month" and we had a big laugh
  • DesiLurker 8y ago
    My somewhat more nunanced retort to such kind is that it depends how much of this work is linear and how much non-linear and how are they naturally occurring. non-linear work may mean things like understanding a complex codebase or developing an algorithm. these dont speedup by adding more people ( what I dont say is these may speedup by adding more quality/unfragmented hours to the individuals doing it). However stuff like refactoring codebase or minor bugfixes may benefit by adding more engineers. Unfortunately, the problem then becomes defending whatever timeline you have in mind for non-linear work. also doing too much of this can give bully managers an opportunity to nitpick and micromanage the whole thing.
• hateful 8y ago
  > You need to be willing to endure the discomfort of looking someone in the face, saying “I don’t know”, and then standing your ground when they pruessure you to lie to them. This. I have PMs who will ask me over and over until I give a number and I've learned to stand my ground. Because if I don't, I end up being responsible for the estimate I've given (as I should). Now I make it clear that I will not give a number until I know more. Just a few weeks ago I was asked to give an estimate of how long it would take to do an integration with something I've never used before. I said, "I need 1-3 days to learn the product enough to give an estimate". What I get back is "can't you just give WAG". But this time around I said "You have two choices, 1. you give me time to learn what I need and then I'll give an estimate or, 2. Find someone who already knows the product to give you an estimate"
  • jolmg 8y ago
    To anyone else that doesn't know what WAG is, it's apparently "Wild Ass Guess".
    • SketchySeaBeast 8y ago
      I find that SWAG sounds better, and let's you add "Scientific" to the front of it.
      • jolmg 8y ago
        "Scientific Wild Ass Guess" sounds better? I think I'd just stick with "educated guess". I wouldn't even make an acronym out of it.
        • SketchySeaBeast 8y ago
          "SWAG" sets the expectations much better than "educated guess"- you're saying "I got very little idea, but you really want a number, so here's a number". "Educated guess" sounds much more like you've got a good idea, which using the term "SWAG" is trying to avoid.
• duxup 8y ago
  Also clear communication (although you are pretty much describing that too). I had a friend who had an unusually high frequency of conflicts with various management, project managers (I expect there are always some, but this guy had a lot of bad experiences). He showed me an instant message conversation: PM: "Is X done?" Dude: "Yes, but a, b, c is not done" A, b, and c were parts of X's requirements. Now the project manager or such should have been able to read between the lines, but man don't lead with "Yes" and actually describe a situation that is "No".
• dboreham 8y ago
  It's important to realize that the workplace often involves being subjected to what is really a kind of psychological abuse. It is not, I think, a coincidence that we are learning that many "stellar managers" turn out to be abusers, e.g. guilty of sexual harassment. What you're describing is in psychological terms thought of as "maintaining boundaries" against a person who is intent on transgressing those boundaries for their own gain or amusement. If you validate the invalid assertions of these abusers (e.g. that some unclear task can be estimated with certainty) then you're enabling the abuse.
  • afarrell 8y ago
    I think “abuse” is an ill-defined enough term that I’m not sure it adds clarity to this discussion without setting out a definition. Its an important subject and might be a really important lens through which to view this, but as someone who has been searching for a really clear-cut definition of “emotional abuse” since my childhood, and who has seen a lot of acrimonious conversations about it since then...I worry that the framing adds more smoke than light to the discussion. :( Do you have a good definition? One whereby a scrupulous person can confidently judge “am I acting abusively?” correctly?
• a_c 8y ago
  I always consider four factors in estimating software cost - the scope of the task - the resource/people you have - the confidence in the resource/people - and the dependency on both the resource and the task Estimation goes wrong in many ways. In my experience, I categorize as follow: - estimated by non-technical PM, unable to gauge technical/business complexity - estimated too early in development life cycle. Often time someone come up with idea X then ask right away "shouldn't be difficult, how long will it take" - no view on team member's productivity due to lack of measurement or measuring the wrong thing - not considering dependency in the development cycle. e.g. The question "whether our only backend engineering available for the task" is often omitted - not considering testing, documentation, 3rd party integration/procurement, maintenance and deployment cost The common practise of coming up a number, then double, or maybe triple it up to make the estimation does not address why estimation is off. Mis-estimation is a symptom. The cause and the cure lies in the people