Requirements volatility is the core problem of software engineering

I will say that our experience is that the happy path for virtually any customer is to ship the MVP as soon as humanly possible. This also means each new/revised feature after the fact. Only once the customer is actually screwing around with your app or feature will they start to develop a true understanding of what is unfolding relative to their daily life or business.

Our customers have extremely high expectations for the quality of output from our application. Their entire business hinges on whether or not we marked a specific checkbox correctly on one of many insanely-complex forms. We started out on this project with a mentality of "its gotta be perfect and we gotta be done at some point". As a result, our development cycles dragged on for months with the customer testing everything all at once on a single "drop dead day". Thankfully, we were able to get away from this mindset. We went from 'almost killing the company' to 'everyone is extremely happy' simply by delivering features to customers on a daily basis. Having that nearly-immediate feedback on new code from the customer means that the responsible developer likely still has most of the abstract concerns loaded into their mental cache and can quickly iterate if needed.

One other aspect that really started putting leverage behind us was building our own integrated tools for easily investigating exceptions or other issues in customer environments. If a user of our application experiences an exception, we are typically reviewing it within 5 minutes (without them having to report it to us explicitly), and if its a trivial affair, a build with a fix would be available for update that same day. Having the ability to trace user events through our application is probably the single most impactful troubleshooting tool available to us aside from the raw logs.

Ultimately, all of the above is the acknowledgement by us that software development is a very hazardous affair, and that we need processes and tools available for rapidly engaging these hazards when they arise. The sooner you realize you have the wrong answer to a problem, the sooner you can go off and find the correct one.

Buildings certainly do change. I just finished 3 months of work on a structure that was "finished" 20 years ago. We had the client coming to us with changes to our changes several times a week.

The problem with software is that we don't build it in a way that makes changes easy (or at least not all the types of changes that clients frequently want to do), and we do a terrible job of communicating the costs of changes.

Give me any program, and I can change a couple words in its requirements which would cause more than half of its lines to need to be changed. That's just how we write software today.

(We diligently made 'time_t' a typedef, and then we embedded the physical size of it in every file format and API and protocol so we can't actually change it without breaking everything.)

Maybe we need a new type of specification system, to encode the distinction between "this is a decision which is immensely expensive to change and will necessitate rewriting half the program" and "this is just part of the facade and we can change it cheaply at any time".

> One difference is that a license is required to practice civil engineering.

I've often wondered about this. Who exactly has to be licensed? Are there management layers in civil engineering firms where the license isn't required? I think my point is pretty easy to follow. I'd love for all of us to be licensed to practice software engineering, but I don't hold any hope that it would fix all of the other compounding problems that our industry has as it relates to product/project management and management-born issues.

For example, would being licensed stop executives at a triple-A video game company from prematurely announcing games / release dates, or accepting pre-orders for games that won't be finished on time, and forcing all of the people under then to scramble and crunch and do things that would generally be considered anti-thetical to whatever being licensed in software engineering could mean?

My uncle is a senior partner in a major civil engineering firm and my wife’s best friend is a civil engineer. Everybody who practices civil engineering in Texas must be licensed to be employable. Maybe you could intern without a license, but you wouldn’t be involved with any project related work.

We should ask management more questions, like: how much time do you think that would cost? And keep score of how often they are off.