> 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.