| ▲ | yen223 a day ago |
| The unique thing about estimates in software engineering is that if you do it right, projects should be impossible to estimate! Tasks that are easiest to estimate are tasks that are predictable, and repetitive. If I ask you how long it'll take to add a new database field, and you've added a new database field 100s of times in the past and each time they take 1 day, your estimate for it is going to be very spot-on. But in the software world, predictable and repetitive tasks are also the kinds of tasks that are most easily automated, which means the time it takes to perform those tasks should asymptotically approach 0. But if the predictable tasks take 0 time, how long a project takes will be dominated by the novel, unpredictable parts. That's why software estimates are very hard to do. |
|
| ▲ | wpietri a day ago | parent | next [-] |
| And I'd add that the need for them is a sign they aren't worth doing. As you say, worthwhile software is usually novel. And to justify our expense, it needs to be valuable. So to decide whether a project is worth doing, we're looking at some sort of estimate of return on investment. That estimate will also, at least implicitly, have a range. That range is determined by both the I and the R. If you don't have a precise estimate of return, making your estimate of investment more precise doesn't help anything. And I've never seen an estimate of return both precise and accurate; business is even less certain than software. In my opinion, effort put into careful estimates is almost always better put into early, iterative delivery and product management that maximizes the information gained. Shipping early and often buys much clearer information on both I and R than you can ever get in a conference room. Of course all of this only matters if running an effective business is more important than managerial soap opera and office politics. Those often require estimates in much the same way they're required from Star Trek's engineers: so the people with main character syndrome have something to dramatically ignore or override to prove their dominance over the NPCs and material reality. |
| |
| ▲ | dotancohen 19 hours ago | parent | next [-] | | > worthwhile software is usually novel.
Another type of worthwhile software is business CRUD. And unfortunately in my experience even for these mundane types of tasks time estimates are typically misjudged - for a multitude of reasons.The typical reason is that developers in large teams often don't know all the places where a field may be used - and their IDE could very well miss some. So automated testing or QA finds an issue, and then the unaccounted-for, time-consuming bugtracking begins. CRUD: Create, Read, Update, Delete. Basically just inputting and displaying data from a database. | |
| ▲ | 9dev a day ago | parent | prev | next [-] | | > As you say, worthwhile software is usually novel. This is an interesting assumption. I’d argue that the overwhelming majority of software is the most boring LoB CRUD apps you can imagine, and not novel at all. Yet, people need to estimate the tasks on these projects as well. | | |
| ▲ | wpietri a day ago | parent | next [-] | | And starting in the late 1970s, there were tools available to simplify building LoB CRUD apps. [1] That has continued with things like Rails and Salesforce and no-code tooling. If something is truly boring in software, it gets turned into a library or a tool for non-programmers to use. Our value is always driven by the novelty of the need. And no, people don't need to estimate the tasks. My dad did LoB apps in the 1970s to the 1990s. E.g., order entry and shop floor management systems for office furniture factories. His approach was to get something basic working, see how it worked for the users, and then iteratively improve things until they'd created enough business advantage and/or cost savings to move on. Exploratory, iterative work like that can at best be done with broad ballpark estimates. I grant that people want estimates. But that is usually about managerial fear of waste and/or need for control. But I think there are better ways to solve those problems. [1] e.g., https://en.wikipedia.org/wiki/DBase | | |
| ▲ | 9dev 18 hours ago | parent [-] | | All of that is besides the point. People need to estimate their tasks if their managers want them to, and no amount of philosophical navel-gazing will change that. | | |
| ▲ | wpietri 12 hours ago | parent | next [-] | | I want to be clear that I am being entirely practical here. This is not navel-gazing. I am describing something that works. That has worked for me and others for decades. And yes, if you are in an environment where people with power want things, you have to take that into account. But no, we don't have to just blindly do what people with power ask. The difference between being a professional an a minion is that professionals know much more about the work and how to do it than the people paying them. Personally, I think we are professionals, which gives us a variety of responsibilities not just to the person with the money, but to the profession and society at large. Does that mean I never have given estimates? Not at all. But it does mean that if somebody asks me to do things in a way I think suboptimal, I'm at least going to say, "Hey, there's a better way to satisfy your goals here." And then I'm going to help them learn enough about the better way that they're at least willing to try it. | |
| ▲ | xGLaDER 17 hours ago | parent | prev [-] | | Because "the manager says so" or because "estimates actually add some value"? I think it's important that our "work culture" allows us to critique why we do certain tasks. When push comes to shove, I guess a manager can say: "Because I say so!", but I also hope those kind of managers are few and far between. | | |
| ▲ | 9dev 16 hours ago | parent [-] | | Both, kind of. The demand to have at least a rough estimate when something will be available is justified IMHO—other departments obviously need to maintain their own timelines and schedule work that depends on output from engineering. Also, I wholeheartedly agree that we do need to question the work culture we follow and the measures we make, and that managers with control issues shouldn't dictate them. On the other hand, the point I was getting to is that a critique of estimation that amounts to "the work I do is so bespoke and unique and novel and important that I can't be bothered to estimate how long it'll take", is just… ignorant. Most software engineers are not lone wolf 10X wizards without any accountability, have managers and other departments to report to, and thus are not eligible to make that point. | | |
| ▲ | wpietri 12 hours ago | parent | next [-] | | This is a gross and misleading caricature of what I'm saying. I prefer this approach precisely because it increases accountability. If you'd like to learn what I'm actually suggesting, I'm happy to answer questions. Or you can read many of the things that have been written by other people on the topic. | |
| ▲ | franktankbank 12 hours ago | parent | prev [-] | | > the work I do is so bespoke and unique and novel and important that I can't be bothered to estimate how long it'll take This absolutely can be the case some of the time though. I've never pressed back on estimates of standard work but it can be a real bastard to have to work within the "process" when you are slaying a truly novel beast. Having some jackass pestering you for updates on how long it takes to climb the beanstalk and find the golden harp is just too much. |
|
|
|
| |
| ▲ | codr7 a day ago | parent | prev [-] | | But it's doing something novel, something the same people haven't done before, otherwise there would be no point in writing it. | | |
| ▲ | 9dev 18 hours ago | parent [-] | | Sure you can move the goalposts here, but OP clearly meant to say software tasks cannot be estimated because people only work on novel problems, since everything else is "not worth doing" (what a massively privileged thing to say by the way). Just because something hasn't been done the exact same way you're doing, that doesn't mean you can't apply a generic solution. I have never changed a tyre on an SUV before, yet I do know how to do so based on my previous experience with a sedan. The same applies to a car mechanic; even if I bring a brand new car to the workshop they have never seen before, I can and should expect them to be able to (at least roughly) estimate how long a tyre change is going to take. |
|
| |
| ▲ | davidhyde a day ago | parent | prev | next [-] | | < “Those often require estimates in much the same way they're required from Star Trek's engineers: so the people with main character syndrome have something to dramatically ignore or override to prove their dominance over the NPCs and material reality.” This is so good. | | |
| ▲ | wpietri a day ago | parent | next [-] | | Thanks. It was hard won. I spent maybe a decade naively thinking that if we just made software methods that worked in service of stated business goals and values, they'd get adopted and we'd all live happily ever after. It took me a long time to come to grips with the POSIWID [1] version of the purpose of planning and estimates. One of the things that really blew my mind is Mary Poppendieck's story about how they built the Empire State Building on time and under budget even though they didn't have it fully designed when they started. [2] Different, more effective approaches are not only possible, they exist. But they can no longer win out, and I think it's because of the rise of managerialism, the current dominant ideology and culture of big business. [3] [1] https://en.wikipedia.org/wiki/The_purpose_of_a_system_is_wha... [2] Talk: https://www.infoq.com/presentations/tyranny-of-plan/ And transcript: https://web.archive.org/web/20140311004931/https://chrisgagn... [3] See, e.g., https://www.amazon.com/Confronting-Managerialism-Business-Ec... | | |
| ▲ | davidhyde 16 hours ago | parent [-] | | Thanks for the links. To the limit of my influence I try to protect my team from distractions, be fluid about methodology (constant agile churn can be depressing), limit the toxicity of pull requests, and to spend as much time with them as I can. A happy team is a productive team. Oh and I try not to work with leaders who obsess over Gantt charts. To me estimates are more about trust and respect rather than metrics and velocity. It has to be the right kind of company though. |
| |
| ▲ | Izkata 7 hours ago | parent | prev [-] | | Further: In The Next Generation, when Scotty shows up, he mentions to Geordi he anyways padded his estimates because he knew Kirk would do things like that. |
| |
| ▲ | bpt3 a day ago | parent | prev [-] | | The solution you described is basically agile, and that definitely includes estimates and deadlines. | | |
| ▲ | mpyne a day ago | parent | next [-] | | There are agile methods that forgo estimates and deadlines though This is what "agile" is: https://agilemanifesto.org/ More specific methodologies that say they are agile may use concepts like estimates (story points or time or whatever), but even with Scrum I've never run into a Scrum-imposed "deadline". In Scrum the sprint ends, yes, but sprints often end without hitting all the sprint goals and that, in conjunction with whatever you were able to deliver, just informs your backlog for the next sprint. Real "hard" deadlines are usually imposed by the business stakeholders. But with agile methods the thing they try to do most of all isn't manage deadlines, but maximize pace at which you can understand and solve a relevant business problem. That can often be just as well done by iteratively shipping and adjusting at high velocity, but without a lot of time spent on estimates or calendar management. | | |
| ▲ | bpt3 a day ago | parent [-] | | Yes, people keep linking to the agile manifesto as if it's some sort of amulet protecting software developers from any sort of accountability or responsibility for their work product in a professional setting. It seems like you acknowledge some amount of estimating is needed and I agree that there is an overemphasis on estimation in many places, but I'll ask you the same thing I asked others, which is: How do you do either of the following without spending any time at all on estimates? "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale." "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." | | |
| ▲ | wpietri 21 hours ago | parent [-] | | I addressed the rest elsewhere, but done well a lack of estimates makes people more accountable. If I am shipping something every week (or as is common for my teams, more often), stakeholders can directly evaluate progress. There's no snowing them with paperwork and claims of progress against semi-fictional documents. They see what they see, they try it out, they watch people use it. The reality of use is what we in software are ultimately accountable to, and that's what I am suggesting people optimize for. Closing that feedback loop early and often builds stakeholder trust such that they stop asking for elaborate fantasy plans and estimates. | | |
| ▲ | bpt3 20 hours ago | parent [-] | | You replied to me in like 10 different places, nearly all of which are in responses to posts that weren't directed at you, so I'm trying not to fragment this discussion too much. I will ask this here: If you are shipping code to production on a weekly basis, is that not a schedule, also known as a deadline for delivery? If you expect to ship code to production every week, how do you know whether there will be something to ship without doing any estimation of the effort and time required? | | |
| ▲ | wpietri 11 hours ago | parent | next [-] | | It is not a schedule, it's a standard. One I normally try to exceed. We ship when things are ready, which for my current team is ~2-3x/week, but in the past I've had teams that were faster. We know that there will be things to ship because we try to break the work down into small units of deliverable value by focusing on seeking the highest-value things to do. Large requests are typically composed of a bunch of things of varying value, so we split them until we find things that advance the needs of the user, the customer, or the business. One that's often not intuitive to people is the business need for getting information about what's truly valuable to some part of the audience. So we'll often ship a small thing for a particular audience and see how they react and what actually gets used. (You can save an amazing amount of time by not building the things nobody would end up using.) Sometimes we can't figure out how to break down something smaller enough that we have something to release right away. Or sometimes a chunk of work surprises us and it drags out. We avoid that, because compared to working on smaller things, it's much less comfortable for both developers and business stakeholders. But if it happens, it happens. We try to learn from it for the next time. Regarding deadlines, we sometimes have them. Broadly, efforts break down into two categories: driven by date or driven by need. For the former, releasing early and often means we adjust scope to hit the date. For the latter, scope is primary and they get stuff when they get it. Either way because the business side sees steady improvement and has fine-grained control over what gets shipped, they feel in control. This can be a learning experience for business stakeholders used to waterfall-ish, plan-driven approaches. But I have never once had somebody successfully work this way and want to go back. I have, however, had some product managers get thrown back into document-driven development and tell me how much they missed working like we did. | |
| ▲ | kragen 17 hours ago | parent | prev [-] | | No, shipping code to production on a weekly basis is not a deadline. A deadline is a time by which a task must be completed. A task is something like "fix bug 3831" or "allow users to log in with OAuth2". "Ship code" is not, in any useful sense, a task. Such "timeboxed iterations" can indeed result in "shipping" a null update. Unless you have a time-consuming QA gate to pass, that's not very likely, especially on a team containing several people, but it can happen. You don't know that you will have "something" to ship. Typically we try to break changes down into shippable tasks that can be done in under a day, so the expected number of tasks completed by a four-programmer team in a week is on the order of 30, or 15 if you're pairing. For this to fall all the way to 0, everybody has to be spending their time on things that could not be thus broken down. It's pretty unlikely to happen by chance. But sometimes a difficult bug or two really is the thing to focus on. In XP, estimates are used for prioritizing which tasks to work on and which tasks to break down into smaller tasks. The "product owner" is supposed to choose the tasks that have the most user value for the estimated cost. But those estimates aren't commitments in any sense; they're guesses. Sometimes tasks take more time than estimated; other times, they take less. This is the reason for the shift to estimating in "story points": to prevent the estimates from being interpreted as referring to a period of time. If someone in your organization is interpreting estimates as commitments, this can have a corrosive effect on the accuracy of those estimates, because estimators respond by padding their estimates, in inconsistent ways. Often this destroys the usefulness of the whole iteration planning process, because the project owner no longer knows which tasks are the easiest ones and thus worth doing even if the benefit is marginal. Organizations can recover from this pathology in a variety of ways, but often they don't. Eliminating estimation is one response that sometimes works. | | |
| ▲ | wpietri 11 hours ago | parent | next [-] | | Yes, this sounds very familiar to me. I started with dates and went to story points used to estimate dates. Then as we turned up the release cadence, we eventually dropped estimating altogether, even in points, because it wasn't really helping anything. That doesn't mean we refuse to solve the problems that estimates are used to solve. E.g., "Can we have something by the big conference," or "Can we keep our customers happy." We just solve them other ways. And totally agreed about the corrosive effect of treating estimates as commitments. It's such a negative-sum game, but people play it all the time. | |
| ▲ | bpt3 9 hours ago | parent | prev [-] | | I already said this to your fellow interlocutor who is also responding to nearly every comment of mine with the same thought process, but I'll say it here as well in different terms: The product owners, customers, salespeople, supervisors, peers, etc. you interact with as part of the software development process on any project outside of a personal hobby don't care about your semantic games. If functionality is needed in an application, and they ask you to implement it, and you agree, there is no real-world scenario where they just say "Cool, I'll sit idly by while you work at this until you declare it ready, and then and only then will I let anyone else know about it or take any action on its supposed existence," and repeat that for every piece of functionality you implement in perpetuity. And if you keep failing to deliver required functionality over time, no one is going to accept your arguments that: "Oh sorry, our weekly deliveries to production aren't a deadline, it's a timeboxed iteration",
"Oh that estimate wasn't a commitment to do anything, we work on our own schedule", and so on. Yes, the relationship between developers and "other stakeholders" can turn toxic, but in most organizations the developers don't have much power, probably due to repeated attempts to play the games you've laid out above. The way to combat that is to be reliable and professional so your team has the authority to stand their ground on the difficulty of a given task, not effectively refuse to participate in what is a completely reasonable conversation about the relationship between your work and the objectives of the organization. |
|
|
|
|
| |
| ▲ | Mtinie a day ago | parent | prev | next [-] | | It’s Agile philosophically, and how it should be. But that is rarely how it works. In the dozens of different projects across ten or twelve companies I’ve had insight into, “doing Agile” is analogous with “we have a scrum master, hold stand ups, and schedule iterations” while the simple reality is “Agilefall.” | | |
| ▲ | bpt3 a day ago | parent [-] | | Agreed, but the parent poster said that estimates shouldn't be done at all, which is not a legitimate argument to make in any scenario. | | |
| ▲ | wpietri a day ago | parent | next [-] | | I have had many successful projects where we spent approximately zero time on estimates. The fact that a successful approach is culturally seen as illegitimate to even talk about is a great example of why I wrote that last paragraph. | | |
| ▲ | awesome_dude a day ago | parent [-] | | Whenever there are constraints (money, time, resources) there are going to be estimates and prioritisation. You might be speaking a little more broadly than I am interpreting. | | |
| ▲ | lmm 17 hours ago | parent | next [-] | | Research is subject to constraints of money, time, and resources, but is not normally estimated in the sense that software industry people would use the term. | | |
| ▲ | awesome_dude 3 hours ago | parent | next [-] | | Research is estimated, sometimes those estimates are hilariously bad (Computer vision is easy, a summer research for a student should be enough), but more often than not it's "We expect that this research will take someone doing a Ph.D approximately 3 - 5 years to do" The entire premise of a project is "Look at this, with the intent to find X, and, if it's not possible, break it down so that we can create more projects to work toward that goal" which is an estimate, or a breakdown into sub projects that also come with estimates. | |
| ▲ | bpt3 12 hours ago | parent | prev [-] | | Yes, yet estimates are still made. The author of the article didn't use some highly formal definition of estimation, didn't imply one, and seems to be focused on devops (not software development) as a practitioner. Estimates are difficult, and in unhealthy environments are weaponized against developers. That doesn't mean they're unnecessary or impossible. | | |
| ▲ | awesome_dude 3 hours ago | parent [-] | | I think that the replies I am getting are demonstrating why developers have estimates used against them - people forget that they are estimates, and they also forget that when new information comes to hand that invalidates that estimate a completely new one may need to be created to take into account the new data. If developers (or anyone giving estimates) discovers that the initial estimate was based on faulty information then they need to push that information back to whomever they are reporting it to (Team Lead, Product Owner, Manager, customer, angel investor...). The receiver of that information then needs to decide on how to react according to the changes. | | |
| ▲ | bpt3 20 minutes ago | parent [-] | | Yes, agile is a reaction to spreadsheet driven development and some very dumb ways of tracking progress towards completion and managing work in general. In my experience, people don't forget they're estimates, they just want to force developers to meet whatever they agreed to that's most convenient for management. If you want to fight back against that, my experience has been that giving terrible estimates or refusing to give them at all will not result in more autonomy or authority. |
|
|
| |
| ▲ | wpietri a day ago | parent | prev [-] | | On the contrary, constraints often mean you don't need formal estimates. (I'll come back to prioritization in a sec.) Startups are a great example. When you raise your first chunk of money, the size of that isn't really driven by a carefully considered, detailed plan with engineering hours estimated per task. What you get is basically determined what's currently fashionable among angels and small-end VCs, plus who's doing your fundraising. (If you're Jeffery Katzenberg and Meg Whitman, you can raise $1bn. [1] https://en.wikipedia.org/wiki/Quibi But the rest of us have to make do with what we can get.) So at that point you have a strong constraint (whatever you raised) and some relatively clear goal. As I said, cost isn't nearly as relevant as ROI, and nobody can put real numbers on the R in a startup. At that point you have two choices. One is just to build to whatever the CEO (or some set of HiPPOs wants). Then you launch and find out whether or not you're fucked. The other is to take something akin to the Lean Startup approach, where you iteratively chase your goal, testing product and marketing hypotheses by shipping early and often. In that later context, are people making intuitive ROI judgments? Absolutely. Every thing you try has people doing what you could casually call estimating. But does that require an estimation practice, where engineers carefully examine the work and produce numbers? Not at all. Again, I've done it many times. Especially in a startup context, the effort required for estimation is much better put into maximizing learning per unit of spending. And how do you do that? Relentless prioritization. I was once part of a team that was so good at it that they launched with no login system. Initial users just typed their names in text fields. They wanted proper auth, and eventually they built it, but for demonstrating traction and raising money there were higher priorities. It worked out for them; they built up to have millions of users and were eventually acquired for tens of millions. On very little investor money. Being great at prioritization makes estimation way less necessary. The units of work get small enough that the law of large numbers is on your side. And the amount of learning gained from the things released change both the R and I numbers frequently enough that formal estimates don't have a long shelf life. So I get what you're saying in theory, but I'm telling you in practice it's different. [1] https://en.wikipedia.org/wiki/Quibi | | |
| ▲ | awesome_dude a day ago | parent [-] | | Wait, your first example is "We raised X dollars" which is a literal estimate of the worth of the company? I think you are well missing the point - everything you put into your rebuttal is about estimates - in time, money, or resources | | |
| ▲ | wpietri a day ago | parent [-] | | If you're saying there's some sort of wisps-and-moonbeams notion of estimation in everything that we do, sure. I'm not going to argue with that. One world, brah. What I am talking about here, though, is a practice of software estimation where programmers produce detailed numbers on the amount of time requested work will take. Which is certainly the common meaning of estimating around here, and also what the original article is about. | | |
| ▲ | awesome_dude 21 hours ago | parent [-] | | "Brah" I mean, if this is upsetting you, take a minute and go for a walk. > You might be speaking a little more broadly than I am interpreting. (Or I could be interpreting it more broadly) In either case I don't think your response is apt | | |
| ▲ | wpietri 21 hours ago | parent [-] | | I'm not upset. But as far as I can tell you've wandered off into some sort of philosophical space when I'm speaking of practicalities, without apparent recognition of the transition. I thought that was a bit ridiculous, something from the "wow dude have you ever really looked at your hand" school of conversation, so I made a joke. Apparently the joke didn't land for you. Alas. |
|
|
|
|
|
| |
| ▲ | collingreen a day ago | parent | prev [-] | | I, and others, don't agree with the blanket statement that "no estimates" is not a legitimate argument in any scenario. Can you expand on why you think there isn't a single case where estimates don't add value? Similarly, is there anything specifically in that post's claims that you think was incorrect, leading to their false conclusion? | | |
| ▲ | bpt3 a day ago | parent [-] | | Okay, a scenario where you're building a hobby project alone and you don't care if or when it gets finished would be one where estimates aren't needed. There is no scenario where it's appropriate or necessary when developing software professionally or even as a side project where others are expecting you to complete work at some point. One of the many misconceptions in the original comment in this thread is that "worthwhile software is usually novel", which is not the case without a very specific and novel definition of worthwhile that I don't believe was intended. | | |
| ▲ | kragen 17 hours ago | parent [-] | | If software isn't novel, that means some other, existing software does the same thing just as well in the same way on the same platform. So, unless it's a hobby project you're building alone, why don't you just use the existing software? I think that writing software that isn't novel fails to be worthwhile by a perfectly ordinary, mainstream definition of "worthwhile". | | |
| ▲ | bpt3 12 hours ago | parent [-] | | So you would consider a CRUD app with some basic business rules to be novel? Basically meaning that any software that requires any development effort is novel? That's a completely valid definition of worthwhile software, but to claim it's impossible to create an estimate to complete said development is absurd. | | |
| ▲ | collingreen 8 hours ago | parent [-] | | You just keep saying things are absurd or obvious but not putting anything behind it. I hope this isn't a semantics game where things like "1 - 6 months" counts as an estimate in this context. The point way back up this thread was accurate timelines for complicated, novel work have large error bars but those error bars aren't as bad as the equivalent error bars on estimating whatever "return" it is being pitted against. | | |
| ▲ | bpt3 6 hours ago | parent [-] | | I wouldn't consider something like "1-6 months" as a valid estimate, as that would indicate there is too much uncertainty and it needs to be broken down into subtasks that can be estimated with much less variance. I've written what is probably several pages now in response to two individuals who are redefining terms in order to play the exact semantic games you mentioned, but in order to claim no estimation of any sort needs to be done. We seem to be done talking past each other now that I explicitly pointed out their usage of non-standard terms and my suspicions of why (having also unfortunately lived through software development managed by Gantt chart and other unpleasant experiences where someone who had no idea what they were managing was in control of a project), which is fine with me. Feel free to describe your experience in practice when working in an organization where software developers answer to no one but themselves and are never asked for any justification for their progress or any projections of when they will be finished (both of which would require estimation to provide). If you are able to tell stakeholders something like you'll be done in 1-6 months or provide no insight at all into when your tasking will be done, do no tracking of progress internally, and perform no collaboration around the completion of synchronous tasks within your team, I'll acknowledge no estimation is taking place during that process. |
|
|
|
|
|
|
| |
| ▲ | wpietri a day ago | parent | prev | next [-] | | I can say with some confidence, having been involved in the movement since before the term "Agile" was coined, that it requires neither. I grant that both of those are common, but that's because the median "Agile" implementation quickly devolved into mini-Waterfall with more hip names. | |
| ▲ | wild_egg a day ago | parent | prev [-] | | I missed that part of the manifesto | | |
| ▲ | wpietri a day ago | parent | next [-] | | Right? For those who want to check, the four values: https://agilemanifesto.org/ And the 12 principles: https://agilemanifesto.org/principles.html But to my dismay, the Agile world quickly got colonized by certification schemes and consultants targeting large companies, so it rapidly turned into something that a lot of the early people were very disappointed with. I wrote about the dynamic some years back: https://williampietri.com/writing/2011/agiles-second-chasm-a... | | |
| ▲ | bpt3 a day ago | parent [-] | | How do you do either of the following without spending any time at all on estimates? "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale." "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." If I was your colleague, had invested in your company, or was considering giving you money to deliver some product and you refused to tell me when you think it'll be done, it would be the last time any of the above ever happened. You wouldn't accept that from any service you were attempting to hire, so I don't know why it would be acceptable for software development. | | |
| ▲ | wpietri 21 hours ago | parent [-] | | I feel like I've already answered the how question elsewhere. But the short version is a product-driven kanban-ish approach with frequent releases, small units of work, and engaged product management focused on actual real-world goals. This approach originated 25 years ago in Kent Beck's "Extreme Programming". Which did start with estimates, but teams doing well at it quickly realized (via said regular reflection) that they could do without it and still deliver well. That some random person on the internet who wouldn't have hired me anyhow will now not hire me is a blow I'll have to learn to live with. But I have literal decades of stakeholders happy working this way. One way that happens is that they pick a date and then we built what fits between now and then. So they get the date, but no promises about what will get delivered. In practice people like this better because beyond a certain very coarse level, estimates are about feelings of engagement and control. What this approach gives them instead is not just feelings, but actual engagement and control. What they get from me is not some unreliable bullshit date, but a commitment to deliver useful things early and often, so that we can together discover something better than their initial visions. And yes, of course I accept this from people who do work for me. My side hustle is starting a pinball museum. When volunteers take on repairing a just-arrived machine, I never ask them for estimates. I ask them to focus on doing it right. They discover problems, figure out how to fix them, and try it out to see if there are more problems. The work takes as long as it takes. Or I hired a friend to design the logo. I never asked for a date. We iterated on it, discovering an number of things along the way, including through user tests. It took a lot longer than I would have guessed, and that's great, because it turned out better than I could have hoped. I understand that this is unfamiliar to people, and apparently it's quite upsetting. But I swear this works. There are more things, Horatio. | | |
| ▲ | bpt3 20 hours ago | parent [-] | | It's not possible to do what you're describing (kanban/XP) for any commercial application or open source project that is intended to be taken remotely seriously without some amount of estimating involved. I saw elsewhere that you're defining estimating as a very detailed and involved process, which the author of the article did not, the person I originally claimed estimates are impossible did not, and I did not. I agree that's not necessary in most cases, if not all, to do the level of estimating you described. And you'll note that I didn't include "people who are doing me a favor" in the list of individuals I'd insist on an estimate from. You don't sound like you're one of these people, but I personally feel that software developers who act like they're performing special incantations over their keyboard and can't be expected to answer to anyone about their deliverables do us all a disservice, though maybe I should just be happy that they allow me to provide an alternative that is much easier to work with and results in additional business for me. | | |
| ▲ | wpietri 11 hours ago | parent [-] | | I am always fascinated when people tell me it is impossible to do something I have done. That plenty of people have done. For decades. But I shouldn't be surprised. Kuhn was not kidding around. And yes, I strongly believe in accountability to business stakeholders, customers, and colleagues. I just think the better way is not paper fantasies, but demonstrated realities. Focusing on working software, customer collaboration, and responding to change, one might say. But people have said it before and it didn't make much difference. | | |
| ▲ | bpt3 9 hours ago | parent [-] | | You aren't doing what you're doing without performing what is commonly known as estimating, you just avoid using what seem like triggering words to you and the one other person who is almost spamming responses to my comments with the same information. See "standard" vs. "schedule", and your very specific and formal definition of an estimate that is almost certainly not what anyone else has been using during this discussion and is not used in practice in most software development shops. Kudos to you for delivering working features on a consistent enough basis that you've earned enough goodwill that people basically leave you to your internal processes and trust that you'll come through for them. I believe that's necessary to have a healthy working environment where you don't end up with what you, I, and every other software developer on earth is trying to avoid, which is an acrimonious relationship with the people with the money where they dictate what, where, when, and how we do our job. But to claim that there is literally no estimating or scheduling taking place as you perform software development is just not true. You can post your disagreement on every single comment I've made on this topic if you want, your existing comments already speak for themselves on the matter. |
|
|
|
|
| |
| ▲ | bdangubic a day ago | parent | prev | next [-] | | the fact that there was a “manifesto” is always been the funniest shit to me (been hacking since the ‘90’s…) | |
| ▲ | bpt3 a day ago | parent | prev [-] | | "Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale." "Working software is the primary measure of progress." "At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly." | | |
| ▲ | wpietri 21 hours ago | parent [-] | | None of which requires estimates. And the bit about working software as the primary measure of progress is specifically targeted against the estimate-driven culture of the time, where people would treat GANTT charts, "percentage complete" numbers, etc, as meaningful measures of progress. |
|
|
|
|
|
| ▲ | lloeki a day ago | parent | prev | next [-] |
| From another thought-experiment-y perspective: Say you have problem A to solve. Then either one of those is true: 1) it has been solved before, ergo by virtue of software having a zero cost of copying (contrary to, say, a nail, a car, or a bridge), so there is no actual problem to be solved. 2) it hasn't been solved before, ergo it is a new problem, and thus at any moment you may turn a stone and discover something that was not foreseen (whether they are rabbits, yaks, bikesheds, dragons, or what have you eldritch horrors) and thus of unknown cost. Any task that cannot be obviously fit into one or the other can nonetheless be split into an assembly of both. Thus any attempt at estimates is as futile as gambling to win, tasks are only ever done when they're done, and "successful estimators" are kings of retconning. It's all make-believe. |
| |
| ▲ | zffr 20 hours ago | parent [-] | | I was with you until this part: > Thus any attempt at estimates is as futile as gambling to win, tasks are only ever done when they're done, and "successful estimators" are kings of retconning. > It's all make-believe. Software estimates are not futile or make believe. They are useful even if they are not always precise. That’s why the industry continues to use them. | | |
| ▲ | kragen 16 hours ago | parent | next [-] | | This argument proves too much: "Bloodletting is not futile or make believe. It is useful even if the patient does not always survive. That's why physicians continue to use it." "Trial by ordeal is not futile or make believe. It is useful even if sometimes Inquisitors reach mistaken conclusions. That's why Inquisitors continue to use it." "Lottery-number-picking systems are not futile or make believe. They are useful even if some players never win. That's why players continue to use them." It is a fully general argument which, if correct, would demonstrate that no practice that had continued for a period of time could ever be ineffective or counterproductive. | |
| ▲ | bonesss 15 hours ago | parent | prev | next [-] | | The amount of tap dancing and philosophizing some developers are willing to do to dodge estimates is hilarious. It’s a skill… a basic part and critical part of engineering. IME the common thread between objectors is that they haven’t made a consistent effort to improve — developing, iterating, and refining their estimation process over time. Yeah, every line of code is a unique snowflake piece of undefinable research the universe has never seen, equally unknowable and inscrutably enigmatic. But the workers at EngiCorp building EngiCorp products using EngiCorp project routines and resources first, second, and third quarter of 2025 are literal world experts at EngiCorp outcomes. They very reasonably should be able to estimate EngiCorp work in Q4, and account for EngiCorp realities, providing maps of future costs that can drive EngiCorp process improvement and investment. If I ask for a decking estimate and get back sophistry and smug incompetence, I’m not talking with a super skilled professional deck builder. Doesn’t matter how they hammer, saw, or draw. | |
| ▲ | Sammi 14 hours ago | parent | prev [-] | | > Software estimates are not futile or make believe. They are useful even if they are not always precise. That’s why the industry continues to use them. The industry continues to fail when trying to use them. They have negative usefulness. |
|
|
|
| ▲ | gilbetron 6 hours ago | parent | prev | next [-] |
| I call it the "Persistent Incompetence of Software Development", which is another perspective on estimation, focused more on expertise. A chef that cooks pizzas, cooks the same pizza over and over again and becomes amazing at it. If you are a developer that writes the same code over and over, you are terrible at software development. A good software developer should always be solving new problems, as by the nature of software, once they solve a problem, they never solve that (exact) problem again. So we are persistently incompenent. Which is why software development can't be estimated, as well. Because it is all, as you say, novel. With infinite error bars. At this point, I can't take anyone seriously that believes software dev can be estimated. |
|
| ▲ | seviu a day ago | parent | prev | next [-] |
| I am in a project where we have to give estimates in hours and days. Needless to say we always underestimate. Or overestimate. Best case we use the underestimated task as buffer for the more complex ones. And it has been years. Giving estimations based on complexity would at least give a clear picture. I honestly don’t know what the PO and TL gains with this absurd obscenity. |
| |
| ▲ | SoftTalker a day ago | parent | next [-] | | The last director I had would ask "is it a day, a week, a month, or a year" he understood that's about as granular as it's possible to be. And he really only used them in comparison to estimates for other tasks, not to set hard deadlines for anything. | | |
| ▲ | skeeter2020 a day ago | parent | next [-] | | This is essentially t-shirt sizing without all the baggage that comes from time. Your boss is trying to use the relative magnitude but it's inevitable that people will (at least internally) do math like "7 day tasks is the same as one week task", or worse over-rotate on the precision you get from day/week/month, or even worse immediately map to the calendar. Suggestion: don't use time. | | |
| ▲ | cnity a day ago | parent [-] | | If you pretend not to use time, everyone will do an implicit time mapping in their head anyway. I've never seen it go any other way. | | |
| ▲ | seviu a day ago | parent | next [-] | | Surprisingly prob yes But still we are much better at estimating complexity Time estimations usually tends to be overly optimistic. I don’t know why. Maybe the desire to please the PO. Or the fact that we never seem to take into account factors such as having a bad day, interruptions, context switch. T-shirt sizes or even story points are way more effective. The PO can later translate it to time after the team reaches certain velocity. I have been developing software for over twenty years, I still suck at giving time estimates. | | |
| ▲ | jrs235 a day ago | parent [-] | | Time estimations, or conversations to days or other units, typically fail because if a developer says 1 day they might mean 8 focused uninterrupted development hours while someone else hears 1 calendar day so it can be done by tomorrow, regardless of if a developer spends 8 or 16 hours on it. |
| |
| ▲ | lmm 17 hours ago | parent | prev | next [-] | | It's probably not possible to fully prevent people from thinking about time at all, but the more friction you can add, the better. | |
| ▲ | SoftTalker 19 hours ago | parent | prev [-] | | That's true. Anyplace I've worked where we did planning poker, "points" were always just a proxy for time. |
|
| |
| ▲ | fallinditch a day ago | parent | prev | next [-] | | Here's my observation: ballparking an estimate for a whole project, in my experience, tends to be more accurate than estimating each task and adding them together. I like to think of this as 'pragmatic agile': for sure break it down into tasks in a backlog, but don't get hung up on planning it out to the Nth degree because then that becomes more waterfall and you start to lose agility. | |
| ▲ | XorNot a day ago | parent | prev [-] | | Knowing nothing else about him, I like him based on this alone. I've been in planning sessions where someone would confidently declare something would take half a day, was surprised when I suggested that it would take longer then that since they were basically saying "this'll be finished mid-afternoon today"...and was still working on it like 3 weeks later. | | |
| ▲ | dgunay a day ago | parent [-] | | Besides the usual unknown unknowns, I've also seen this happen with tasks that involve a lot of coordination in the SDLC. Oh the PR went up at at 2pm PST? Coworkers in EST won't review it until tomorrow. Maybe some back and forth = another day until it clears review. Then QA happens. QA is heavily manual and takes a few hours, maybe with some false starts and handholding from engineering. Another day passes. Before you know it the ticket that took an hour of programming has taken a week to reach production. | | |
| ▲ | jrs235 a day ago | parent | next [-] | | As mentioned in a sibling comment reply: Time estimations, or conversations to days or other units, typically fail because if a developer says 1 day they might mean 8 focused uninterrupted development hours while someone else hears 1 calendar day so it can be done by tomorrow, regardless of if a developer spends 8 or 16 hours on it. | |
| ▲ | jrs235 a day ago | parent | prev [-] | | Are we estimating developer cost (investment cost, writing code only tome), development costs (investment costs including QA time), or time to delivery and first use? People want and use estimates for different purposes. You point out great reasons why knowing what the estimates are for is important. |
|
|
| |
| ▲ | 121789 a day ago | parent | prev | next [-] | | Hours is insane. But ultimately time is money and opportunity cost. Software engineering can’t be the only engineering where you ask the engineers how much something will cost or how much time it will take and the answer is “it’s impossible to know”. Even very inaccurate estimates can be helpful for decision making if they are on the right order of magnitude | | |
| ▲ | zdragnar a day ago | parent | next [-] | | There's two things here that get overlooked. First, people asking for estimates know they aren't going to get everything they want, and they are trying to prioritize which features to put on a roadmap based on the effort-to-business-value ratio. High impact with low effort wins over high impact high effort almost every time. Second, there's a long tail of things that have to be coordinated in meat space as soon as possible after the software launches, but can take weeks or months to coordinate. Therefore, they need a reasonable date to pick- think ad spend, customer training, internal training, compliance paperwork etc. "It is impossible to know" is only ever acceptable in pure science, and that is only for the outcome of the hypothesis, not the procedure of conducting the experiment. | | |
| ▲ | collingreen a day ago | parent | next [-] | | > "as soon as possible after the software launches" This isn't true, just desired, and is one of the main roots of the conflict here. OF COURSE you would like to start selling in advance and then have billing start with customers the instant the "last" pr is merged. That isn't a realistic view of the software world though and pretending it is while everyone knows otherwise starts to feel like bad faith. Making software that works, then having time to deploy it, make changes from early feedback, and fix bugs is important. THEN all the other business functions should start the cant-take-back parts of their work that need to coordinate with the rest of the world. Trying to squeeze some extra days from the schedule is a business bet you can make but it would be nice if the people taking this risk were the ones who had to crunch or stay up all night or answer the page. Trying to force complicated and creative work into a fake box just so you can make a gantt chart slightly narrower only works on people a couple times before they start to resent it. 10x that if management punishes someone when that fantasy gantt chart isn't accurate and 100x that if the one punished is the person who said "it's impossible to know" and then was forced into pretending to know instead of the person doing the forcing. | |
| ▲ | skeeter2020 a day ago | parent | prev [-] | | My take: if they have not done the work to get to at least some degree of a spec, and they won't give you time to review and investigate, they get nothing more than a vague, relative t-shirt size. |
| |
| ▲ | yetihehe a day ago | parent | prev | next [-] | | I think software is one of those VERY rare things, where inaccurate estimates can actually be inaccurate by "orders of magnitude". After 20 years in the field, I still managed to use 2 months of time on a task that I estimated as 10 days. | | |
| ▲ | camel_gopher a day ago | parent | next [-] | | A rule that has suited me well is to take an estimate, double it, and increase by an order of magnitude for inexperienced developers.
So a task the say would take two weeks ends up being 4 months.
For experienced developers, halve the estimate and increase by an order of magnitude. So your 10 days estimate would be 5 weeks. | | |
| ▲ | QuercusMax a day ago | parent | next [-] | | The biggest estimation effort I ever took part in was a whole-system rewrite[1] where we had a very detailed functional test plan describing everything the system should do. The other lead and I went down the list, estimated how long everything would take to re-implement, and came up with an estimate of 2 people, 9 months. We knew that couldn't possibly be right, so we doubled the estimate and tripled the team, and ended up with 6 people for 18 months - which ended up being almost exactly right. [1]: We were moving from a dead/dying framework and language onto a modern language and well-supported platform; I think we started out with about 1MLOC on the old system and ended up with about 700K on the rewrite. | |
| ▲ | yetihehe a day ago | parent | prev | next [-] | | 10 days was already after I used this algorithm. Previous several tasks on that codebase were estimated pretty good. Problem with this is that some tasks can indeed take SEVERAL orders of magnitude more time that you thought. One of the hardest problems with estimating for me is that I mostly do really new tasks that either no one wants to do because they are arduous, or no one knows how to do yet. Then I go and do them anyway. Sometimes on time, mostly not. But everybody working with me already knows, that it may be long, but I will achieve the result. And in rare instances other developers ask me how did I managed to find the bug so fast. This time I was doing something I have never before done in my life and I missed some code dependencies that needed changing when I was revieving how to do that task. | |
| ▲ | bdangubic a day ago | parent | prev [-] | | I’ll send my friend that has a construction company to build your next 3500 sq ft house for $13.6 million dollars :) |
| |
| ▲ | bumby a day ago | parent | prev | next [-] | | Something often overlooked in cost/schedule estimates is the nature of joint probability of actions slipping. Action A slips and causes action B to slip. I think software is tougher to estimate because the number of interfaces is often much higher, and sometimes more hidden, than in hardware. | | |
| ▲ | bdangubic a day ago | parent [-] | | as opposed to say building a house where framing can totally slip while we run electricity and build a roof floating in mid-air software is only tougher to estimate if incompetent people (vast majority of the industry, like 4+ million) is doing the estimating :) | | |
| ▲ | yetihehe 18 hours ago | parent | next [-] | | My home construction slipped 6 months on 2 year build time. It happens in construction very often. > software is only tougher to estimate if incompetent people (vast majority of the industry, like 4+ million) is doing the estimating :) No, it is tough to estimate, but not only for incompetent people. And "incompetent" can be stretched to "don't know what he's doing", which is how I operate most of the time. I don't know what really needs to be done until it's done. Main part of my work is research on what actually needs to be done, then "just" implementing it. If I waited with estimating until I know what needs to be done, I would spend 3/4 time estimating and then 1/4 with clear understanding and good schedules (example description: I will be clicking keys for 5 hours). | | |
| ▲ | rkomorn 18 hours ago | parent [-] | | > My home construction slipped 6 months on 2 year build time. It happens in construction very often. Tangent, but I have at least 3 friends that would've (in retrospect) been nothing short of ecstatic if their home construction had "only" slipped 6 months on a 2 year timeline. |
| |
| ▲ | bumby 12 hours ago | parent | prev [-] | | That’s a bit of a strawman considering I was deliberate in saying hardware interfaces are limited and not saying they are zero. The number of interfaces in software is often going to be orders of magnitude greater. The network effects and failure modes will often increase geometrically with the number of interfaces. In fact, big construction design firms have tools to easily identify and mitigate the “clashes” you bring up and those tools tend to work well because there is a finite number and the designs are well-documented (as opposed to software where changes are relatively cheap and easy so they often occur without documentation) Saying incompetence is the reason is a trivial rebuttal that ignores the central claim about complexity. It’s like saying “the reason why we don’t have a theory of everything is because we don’t have competent physicists” |
|
| |
| ▲ | Scarblac a day ago | parent | prev [-] | | That's a factor four or five ir so, so still less than an order of magnitude. |
| |
| ▲ | njovin a day ago | parent | prev | next [-] | | The next natural progression of this line of discussion between "the business" and engineering is for them to agree on a time range as an estimate. Engineering doesn't want to say it'll be done in 6 weeks, but they feel okay saying it will take between 4 and 20 weeks so this estimate is accepted. You can guess what happens next, which is that around week 8 the business is getting pretty angry that their 4-week project is taking twice as much time as they thought, while the engineering team has encountered some really nasty surprises and is worried they'll have to push to 24 weeks. | | |
| ▲ | skeeter2020 a day ago | parent [-] | | it is still better to give a range though because 1. it explicitly states the degree of unknown and 2. no boss is going to accept 4-20 weeks, which means you start talking about how you can estimate with better accuracy and the work required to do so, which is a major goal of planning & estimation. |
| |
| ▲ | lmm 17 hours ago | parent | prev [-] | | > Software engineering can’t be the only engineering where you ask the engineers how much something will cost or how much time it will take and the answer is “it’s impossible to know”. Because it's not engineering at all. But even if it was, plenty of engineering projects are impossible to estimate - the ones that are doing something novel - and disliking that fact doesn't make it go away. > Even very inaccurate estimates can be helpful for decision making if they are on the right order of magnitude If what the business wants is an order-of-magnitude, they should ask for that; often (not always!) that's a lot easier. |
| |
| ▲ | Scarblac a day ago | parent | prev [-] | | > I honestly don’t know what the PO and TL gains with this absurd obscenity There are marketing campaigns that need to be set up, users informed, manuals written. Sales people want to sell the new feature. People thinking about road maps need to know how many new features to can fit in a quarter. Development isn't the only thing that exists. |
|
|
| ▲ | Scarblac a day ago | parent | prev | next [-] |
| Another reason is that figuring out what the software to be written should actually do, and how it should work, is work that is part of the project and the time it will take needs to be estimated. As well as the actual development work that will result, which isn't known yet at the time of estimation. |
|
| ▲ | a day ago | parent | prev | next [-] |
| [deleted] |
|
| ▲ | analog31 a day ago | parent | prev | next [-] |
| "... anybody with any brains has already left town..." -- Bob Dylan Anybody with any business experience has already isolated themselves from the certainty of software project failure, where "failure" is a euphemism for "late." So it doesn't matter if software can't be estimated. This can be nerve-wracking to a beginner, but one gets used to it over time. |
|
| ▲ | harrall a day ago | parent | prev | next [-] |
| As I’ve gotten older, I find this to be untrue. Estimating the unknown is itself a skill. It’s like choosing to crash random parties everyday — at first, exceptionally novel but facing the unknown becomes itself mundane. Humans adapt. They build mental modals to approach the unknown and these mental modals are predictable. I just don’t think most people get much practice. |
|
| ▲ | tbrownaw 21 hours ago | parent | prev | next [-] |
| > If I ask you how long it'll take to add a new database field, and you've added a new database field 100s of times in the past and each time they take 1 day, your estimate for it is going to be very spot-on. But in the software world, predictable and repetitive tasks are also the kinds of tasks that are most easily automated The slow part isn't following a written "log in and run ALTER TABLE" runbook, it's the review of "does this solution make sense given what we're trying to do". |
|
| ▲ | deepsun 17 hours ago | parent | prev | next [-] |
| Spot on! Now add one more dimension (from machine learning projects and pretty much other research fields) -- you also never know if the result are going to even work. Maybe the data just doesn't have the correlation you want. Maybe you just didn't try harder, never know for sure. But owners reasonably demand some estimations. |
|
| ▲ | eb0la a day ago | parent | prev | next [-] |
| That's the point: how can you tell WHEN you are going to reach a place you've never been before traveling an uncertain path? Making mistakes over and over again.
And adding a lot of time buffers just to be safe |
|
| ▲ | raw_anon_1111 a day ago | parent | prev | next [-] |
| There is very little novel about most B2B CRUD and internal bespoke apps that most developers are doing. The novel part if any is implementing the business vertical logic |
|
| ▲ | IanCal a day ago | parent | prev | next [-] |
| Repetitive and easy or worth automating are not the same. The fundamental problem is that a setup capable of solving any of the requests that come to it is as complex as just a whole programming language and then you’re back to square one. |
|
| ▲ | GMoromisato a day ago | parent | prev | next [-] |
| Very insightful. This is also my go-to argument for why software engineering is real engineering. |
|
| ▲ | vegetablepotpie a day ago | parent | prev | next [-] |
| As a project manager, it sounds like you're making excuses. Just give me a number, trust your gut! We have a fundamental failure to communicate, what we're doing. The game project managers and finance believe we're all playing is a regression towards the mean, where everything is additive and rounds up to nice consistent formulaic sums. Whereas software development follows power law distributions. A good piece of software can deliver 10x, 100x, or 1000x the cost to produce it (ex: distribution, cost of delivering another copy of software is near 0 once written). You don't get that sort of upside with many other investments. Finance is happy with an NPV 8% above what they invest in. This means that when software people talk, everything they say sounds foreign, and everyone assumes it's because of jargon. It's not. The fish don't know they're swimming in water. When the fisherman comes, everyone is caught off guard. So we get what the author talks about > The estimates stopped being estimates. They became safety railings against being held accountable for unreasonable expectations. We. Pad. Like. Crazy. Yes this is inefficient. Some project managers recognize this. We get theory of constraints. But rather than cull the layers of hierarchy that lead to the padding in the first place, all the blame for failure goes back to developers. Get hit on the head enough and you will stop acting in good faith and pad to save your ability to feed and cloth yourself. |
| |
| ▲ | joombaga a day ago | parent | next [-] | | It's not obvious to me that we should avoid padding, or why it's seen as undesirable. | | |
| ▲ | vegetablepotpie a day ago | parent [-] | | Padding ties up capital, it reduces credibility, it delays deployment, it adds costs through delay. It is bad for organizations. However, it is a great solution if you're a worker in a bureaucratic environment that can tolerate large costs, but is intolerant of 1-day of schedule slips. It's a great solution for complacent management, who are confused about the game they're playing and wants to report that they're "on track", which means "not late". The agile solution of incremental value delivery is a compromise, and can produce good outcomes for functional changes. But agile has unacceptable failure modes when working on infrastructure and satisfying system constraints. Agile can work okay for programmers, but it's not a solution for engineers. Acknowledging, owning, and managing risk is more scalable, but you have to have leaders who acknowledge that they exist and have the maturity to take on that responsibility. | | |
| ▲ | ryan_lane an hour ago | parent [-] | | > Padding ties up capital, it reduces credibility, it delays deployment, it adds costs through delay. Well done timelines are a negotiation between the stakeholders and engineers. The stakeholders need something done for the business, the engineers give a timeline. If that timeline works for everyone, great. If it doesn't, then the stakeholders will ask if it can be done in a faster time. A timeline that lands on time, or early, is good. The point of timelines is that teams outside of engineering are resourcing their projects based on your timelines. They may have made outside commitments to customers, they may be lining up marketing, they may have embargoed PR, it may be delivered by someone at a conference, etc. A project running late can be catastrophic. Bad customer relations, wasted marketing spend, pulling back stories from PR, delays for dependent teams, etc. You pad to make sure your timelines aren't overly optimistic, because we're all bad at estimating, and it's possible our dependencies are too. By padding, when it comes time to negotiate for shorter timelines, you also have some wiggle room. Bureaucratic environments tend to be larger companies and they care about schedule slips, because they have more teams being impacted, and those teams are handling larger numbers of overall projects. Schedule slips can lead to cascading failures. |
|
| |
| ▲ | Trasmatta a day ago | parent | prev [-] | | > As a project manager, it sounds like you're making excuses. Just give me a number, trust your gut! If we're just making up numbers, why don't you just make it up yourself and save the developers the trouble? | | |
| ▲ | vegetablepotpie a day ago | parent [-] | | Ah! But I want you to own it. If you say it first... you own it. And I do not have to get you to agree to it. | | |
| ▲ | Trasmatta a day ago | parent | next [-] | | This is usually how I get tricked into setting deadlines. I get asked for a "rough estimate", then it magically becomes a deadline. | |
| ▲ | a day ago | parent | prev [-] | | [deleted] |
|
|
|
|
| ▲ | austin-cheney 18 hours ago | parent | prev | next [-] |
| This is going to be immediately downvoted, but whenever I see software developers mention that estimating is uniquely challenging for software it immediately calls out a bunch of red flags. Estimates in software are challenging but no more or less challenging than other industries. Typically the people that single out software as a unique snowflake in the world of delivery and estimation really just say out loud they have no experience in project management and no experience working outside of authoring code. The things that make estimations most challenging in software are the same factors that make estimations challenging everywhere else. |
| |
| ▲ | ctenb 18 hours ago | parent | next [-] | | Can you give an actual counterargument? | |
| ▲ | Capricorn2481 17 hours ago | parent | prev [-] | | I don't think it's unique, but many software projects are inherently prone to big surprises you can't catch until you start the work. I would love to keep estimating and estimating and get an accurate number, but it costs money and, eventually, you're just working on the project. |
|
|
| ▲ | yodsanklai a day ago | parent | prev | next [-] |
| I don't know how typical teams work, but in my case, new projects always come on top of other obligations. It may take 1 day to add the field, but how many meetings, fires, or other disturbances will happen during that day? |
|
| ▲ | bpt3 a day ago | parent | prev [-] |
| If software developers want to be then seriously as a profession, they need to be able to provide and justify estimates for their work. Everything you said could apply to a new bridge, building, pharmaceutical compound, or anything else that is the result of a process with some known and some unknown steps. |
| |
| ▲ | wild_egg a day ago | parent | next [-] | | > Everything you said could apply to a new bridge, building, pharmaceutical compound "Everything"? So > predictable and repetitive tasks are also the kinds of tasks that are most easily automated, which means the time it takes to perform those tasks should asymptotically approach 0. Also applies to bridges? Bridges require a ton of manual human input at every stage of construction, regardless of how predictable and repetitive the work is. With software, we can write software to make those tasks disappear. I've yet to see the bridge that can build itself. | | |
| ▲ | bpt3 a day ago | parent [-] | | 1. When you have meaningful software that can build itself (and I'm not talking about the compilation process), let me know. 2. You can estimate the duration of each step of a process, regardless of how much human involvement is required. | | |
| ▲ | kragen 16 hours ago | parent [-] | | You should be talking about the compilation process, because that's the thing that puts the cost of non-novel software at near zero, and you can't recompile a bridge for free. Estimating the duration of each step of a process only works when you know what the steps are. | | |
| ▲ | bpt3 13 hours ago | parent [-] | | Effectively free distribution is what makes the cost of non-novel software so low. Compilation isn't even needed for executables that can be used as is. That said, implementation is one part of developing software. Design and test are also necessary and can take a non trivial amount of time. And yes, you need to know what the steps are to build something. If you don't, you don't know what you're doing, which is a bad thing. |
|
|
| |
| ▲ | kragen 16 hours ago | parent | prev | next [-] | | Drug discovery chemists do not, to my knowledge, provide estimates on how long it will take them to discover a marketable drug. | | |
| ▲ | bpt3 12 hours ago | parent [-] | | You think the pharmaceutical industry just gives a bunch of resources to chemists, says "godspeed", and waits around for the chemists to report back at their convenience? In my limited exposure to the industry, that's not how it worked. They have budgets, timelines, and progress is tracked as it is determined whether there is a viable path to a marketable drug. |
| |
| ▲ | XorNot a day ago | parent | prev [-] | | Pharmaceutical compounds frequently don't make it to market after significant investment. No one in that industry is giving estimates based on developing brand new drugs - they're giving estimates related to manufacturing lead times, unalterable physics time lines, and typical time to navigate administrative tasks which are well known and generally predictable (but also negotiable: regulations have a human on the other end). All of this after they have a candidate drug in hand. Same story with bridge building basically: no one puts an estimate on coming up with a brand new bridge design: they're a well understood, scalable engineering constructions which are the mostly gated by your ability to collect the data needed to use them - i.e. a field survey team etc. - and also once again, regulatory processes and accountability. | | |
| ▲ | bpt3 a day ago | parent [-] | | Yes, that's my point. There's way more uncertainty in trying to bring a new drug to market or build a new bridge than creating yet another CRUD app, yet somehow they are any able to break these efforts into tasks that can be estimated and tracked and many software engineers think they should be exempt from any accountability to schedule or budget. | | |
| ▲ | Aeolun a day ago | parent [-] | | And do you think those things are delivered on schedule any more often than software projects? | | |
| ▲ | bpt3 a day ago | parent [-] | | Take a look at the top of this thread and see what we're talking about. The fact that people in many industries are not good at estimating doesn't mean that it's impossible in software development specifically and uniquely, as was originally claimed. |
|
|
|
|
