3 ms·

> You are misunderstanding your job. You are a subject expert and paid accordingly. Answer with what the unknowns are, an optimistic and pessimistic take on the

> You are misunderstanding your job. You are a subject expert and paid accordingly. Answer with what the unknowns are, an optimistic and pessimistic take on them, what you could do and how long it would take to lift them. Add a small feature to an existing system. This estimate can be anywhere from several months to a day. Most of the error bars are org and system specific rather than anything to do with the feature. The exact same feature built by the same person in different orgs and different systems can be opposite ends of the range. Seldom do people have the contextual understanding to provide an accurate narrow estimate, particularly since both org and system are in flux. They change constantly. Unseen landmines potentially await in both. > If you don’t, your boss is going to ask you for exactly that in a roundabout way and micromanage you because you are forcing them to do your job. And such orgs take forever to get anything done. > It still baffle me than approximately half of developers don’t understand things which are obvious to any seasoned blue collar worker. Software is probably the hardest kind of engineering you can do. All the system constraints are virtual. Just consider comparing a dirt ground for consistency and behavior vs libc... 304 stainless vs react. You can go deep in both, but a shallow understanding of one takes you much much further than a shallow understanding of the other.

WastingMyTime89 4y ago
> Add a small feature to an existing system. This estimate can be anywhere from several months to a day. That’s extremely untrue in my experience. Sure, hard to interface with systems are a thing and organisational roadblocks happen but an onboarded senior team member can tell you what’s going to take days and what’s going to take months or they have no business being senior in the first place. I feel like my answers in this discussion have been particularly harsh but I would really like people calling themselves software engineers to start acting like some. I think my view on this subject has been strongly shaped by spending most of my career doing software development for industrial companies: people who claim software is particularly complicated just don’t understand and respect how complex the rest of an industrial project is.
- tremon 4y ago
  an onboarded senior team member can tell you You're making an unwarranted assumption here. There's many pieces of software that have no development team at all. There's no one to ask; the last person to touch this software left the company three years ago. All they can tell you about it is how they use it now. It's likely there's at least someone that can explain their business process to you, but identifying them and receiving enough of their time to piece the picture together is another story. And maybe, if you're lucky, that person can tell you what the business process was at the time the software was written, and what has changed since then. But this process can take weeks, and most of the time you're expected to provide an estimate before even talking to anyone from operations. Sure, for internal software with an active maintenance/development team, informed estimates can be given with a relatively high level of confidence. But as an outside consultant working with non-software companies, all estimates are completely made-up based on your reading of the buyer's budget: there are no other data points to base your estimate on.
  - WastingMyTime89 4y ago
    Working in the field, I’m fairly certain you already know that this kind of job always starts by a paid diagnostic and scoping phase which is there to give you the elements you need to do an actual estimation. It’s either that or you are lucky to still be solvent.
    - re-thc 4y ago
      There are lots of places where you get 0 of that before providing an estimate. And yes they are still solvent. As others mention there are lots of unknowns in an organization. I've been in places where the other team involved is across the globe in a different timezone and isn't even actively willing to respond and yet we continue... There are also cases where lots of parts are outsourced and you're lucky to get a reasonable response i.e. changing part x requires vendor a, b, c & d, which have an SLA 1-8 weeks and so you're already starting 4-32 weeks without even working anything else out. If you're really lucky it could still all be done in 1 day. Not sure if you're harsh as you say or just lucky. Not everyone and every team is well organized.

WastingMyTime89 4y ago

> Add a small feature to an existing system. This estimate can be anywhere from several months to a day. That’s extremely untrue in my experience. Sure, hard to interface with systems are a thing and organisational roadblocks happen but an onboarded senior team member can tell you what’s going to take days and what’s going to take months or they have no business being senior in the first place. I feel like my answers in this discussion have been particularly harsh but I would really like people calling themselves software engineers to start acting like some. I think my view on this subject has been strongly shaped by spending most of my career doing software development for industrial companies: people who claim software is particularly complicated just don’t understand and respect how complex the rest of an industrial project is.

tremon 4y ago
an onboarded senior team member can tell you You're making an unwarranted assumption here. There's many pieces of software that have no development team at all. There's no one to ask; the last person to touch this software left the company three years ago. All they can tell you about it is how they use it now. It's likely there's at least someone that can explain their business process to you, but identifying them and receiving enough of their time to piece the picture together is another story. And maybe, if you're lucky, that person can tell you what the business process was at the time the software was written, and what has changed since then. But this process can take weeks, and most of the time you're expected to provide an estimate before even talking to anyone from operations. Sure, for internal software with an active maintenance/development team, informed estimates can be given with a relatively high level of confidence. But as an outside consultant working with non-software companies, all estimates are completely made-up based on your reading of the buyer's budget: there are no other data points to base your estimate on.
- WastingMyTime89 4y ago
  Working in the field, I’m fairly certain you already know that this kind of job always starts by a paid diagnostic and scoping phase which is there to give you the elements you need to do an actual estimation. It’s either that or you are lucky to still be solvent.
  - re-thc 4y ago
    There are lots of places where you get 0 of that before providing an estimate. And yes they are still solvent. As others mention there are lots of unknowns in an organization. I've been in places where the other team involved is across the globe in a different timezone and isn't even actively willing to respond and yet we continue... There are also cases where lots of parts are outsourced and you're lucky to get a reasonable response i.e. changing part x requires vendor a, b, c & d, which have an SLA 1-8 weeks and so you're already starting 4-32 weeks without even working anything else out. If you're really lucky it could still all be done in 1 day. Not sure if you're harsh as you say or just lucky. Not everyone and every team is well organized.