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.