The Waterfall Model works because you know exactly what the solution is before you start coding. That is the whole point of the Requirements Specification and there is no reason today NOT to know everything up front because we have Big Data to draw from: the Business Knowledge Domain, Functions, Tasks, and even Software Patterns. It may take 12 months to understand the Requirements Specification from the Requestor/User, but the maintenance is almost zero because the coding is a translation from the Spec language to the Computer language and easily verified. And the program will work almost flawlessly from day one for the next 5 years or more. Move on to the next project. To start coding before you know what the customer wants is a terrible way of working that leads to the software crisis. The crisis is that the software worldwide is unreliable and bordering on collapse. The customer will also keep adding wants to the existing software as it reveals more possibilities without increasing payment. This is never ending. By documenting exactly what the customer wants (even if it takes 6 months or more) results in a solution and program that is more robust, resistant to change, and avoids bloat. I'm guessing you never tried the Waterfall Model so you have no experience with it. The weakness with the model is the customer: Are they willing to discuss their business requirements to the minutest detail over the next 6 - 12 months before coding starts? Most will see the delay as falling behind the competition and refuse. The others will gamble on a 9 year ROI and they will win if you've done your job properly. The rest may be flattered that someone is so interested in the business that they'll happily talk about it for months on end. And to see it, not only documented in detail, but actually working in practice, is a massive ego boost. And the kicker is bragging rights that it is bug free (mostly), requiring little to no maintenance costs for the rest of its life cycle. Such reliable software is worth far more than agile programming promises. You don't come up with the solution, the customer does because they know what the program must do. If they don't, then you need to get them to find a solution by asking business questions. You may offer alternatives based on software models, but ultimately it is the customer who decides what the software will do. The Software Requirements Document simply shows the customer you understand their solution, that is, you now know how their business works well enough to automate specific parts of it and interface them into their business model. Once they sign off the document, you can now establish a Plan and Design Document to meet the Spec and enlist programmers to code the solution, as Designed, from the Spec, according to the Plan, and using Module folders to track their progress. Finally, the staff will need training on the menu, forms, and data I/O.

Hahaha i love this 🥹

You Sir should be knighted

Yeah - I was kinda surprised with the immediate dismissal of wireframes. Huh? I guess wireframes aren't done by agile? Weird moment, and totally unexplained for us non-initiated.

Yes you can, but it takes a different mindset, a different understanding of what SW dev is really about and so, how to do it. I"d argue that SW dev is a process of learning, and that what we do is learn enough to come up with a design that works for the problem that we are trying to solve, that means that we need to organise to learn. Waterfall works against learning, because the best way to learn is to try ideas out, so effective teams organise themselves to be able to try ideas out, learn from what they find and do more of what works and less of what doesn't. That is not just the "agile" approach, but is also how science and engineering work!

Yeah... you can. Continuous discovery and continuous delivery. Instead of planning everything up front, you first identify the problem, test solutions (ideally solutions that don't require any code) and start building the minimum solution. And you don't stop there, you keep on doing the discovery work, constantly testing the product and new ideas with users. Agile is not doing all the steps of waterfall in repeated increments, it's doing the discovery and delivery all the time.

"without a bare minimum of" --> An engineering principal for over 2000 years....for a reason

"You cannot escape waterfall" - The problem is the timeframe and the false assumptions around designing large systems upfront (one of them is assuming that your design is correct without testing it out and another is that it will rarely change, just to name a few). When you make that timeframe smaller (not months, but days) you get feedback faster, you can improve and evolve in better directions and when you do a mistake (not "if" - you will do mistakes), you can fix and learn faster.

The scary thing is that it works. The whole world runs on software written like that. For all these companies know they are using the state of the art of software development methodology.

You can tell it will be a train wreck from "etimated 3h-15d", then "promise to deliver story points". You can't convert between time and story points, that's the point of them. It's one of those red flags like thinking that more people means less time.

Let's just be clear on terminology here 😉 What you described may have been called agile, but it is very far from agile based on the definitions from the people that invented the concept of "agile development" agilemanifesto.org

@@ContinuousDelivery I think we have all read the manifesto here, but what do you propose that we do? Working in these organisations is like working with flat earthers. No amount of evidence or rational arguments will change their minds. I don’t even think a true agile company disrupting an entire market is going to convince anyone, since there are too many other confounding factors for market success.

@@salvatoreshiggerino6810 choose the org you work in, you live only once. Let evolution take care of the rest.

Nailing down the requirement is a key waterfall skill. It's not impossible, or even particularly hard. But if you haven't got the discipline to do it I suppose you need Agile.

@@_Mentat And it doesn't work. Latest when you spot a hole in the spec the customer will use it to fill the hole and redirect the requirements. And there you go: Change. Agile was invented to work with the real world of (pure) SW development. If you develop close to hardware it may be different, because HW has to be frozen on some point for mass manufacturing.

@@kevinfleischer2049 Our customers sign contracts. They could change the requirements but it would cost them. Mainly they don't. Usually we have a succession of contracts with the same customer and if they want a change or additional functionality it becomes part of the next contract a couple of years later. We're basically doing the same thing over and over again for different customers; "a hole" is not likely.

@@_Mentat agile is not a workaround to not been disciplined enough to nail down the requirement, it is a way to work with constantly changing environment and knowledge (practically, with the real life). Numerous projects have failed as the whole problem they were trying to solve was not actual anymore while they were implementing the solution for it. From the other point, some products have reached huge success by being able to transform dramatically as soon as they observed changing environment.

@@kevinfleischer2049 even for hardware, environment may change dramatically. That's why you want to prototype something first and see user's feedback before enabling full-scale manufacturing of the product. Yes, cycles can be longer, but the whole idea - as quick feedback loop as possible, is the same. And this is especially true now when firmware for a lot of devices can be loaded any time.

I understand the gripe, but i think the implied resolution here is “just let the developers be the local gods of everything and it’ll all just work itself out”. As a developer who has enough trouble keeping up with the current cutting edge of implementation and process best practices, I certainly don’t think that’s very sustainable either. I think the path forward for companies is a model where everybody has their strengths and is respected for the values they bring to the team, but where that input is still not ironclad. If I’m strong in React and CSS, then maybe I can drive the UI discussions but still be receptive to product when something isn’t matching the customer’s mental model of the domain. It i’m an expert in distributed cloud architecture, then I should still be responsive to the idea that I could be building a system that’s hard to work with to satisfy overkill performance expectations. The problem is that today’s waterfall-in-disguise status quo is fundamentally driven by commitment to unreasonable schedules, and that makes people fearful and prone to finger-pointing whenever anything goes differently than the ill-conceived plan, and that’s the kind of the problem that leadership creates and solves.

I've always loved the Cargo Cult comparison. There are literally (figuratively, if you must) rituals, and they're called as such. If we're doing the rituals, it must be Agile; if we pretend to run an airport, then the cargo planes will come back.

It's certainly a cult. They talk of ceremonies, rituals and artifacts. And the believers have religious fervor. The Scrum Masters and Product Owners support it like their (working) lives depended on it. Which they do.

This guy gets it

We need back those traditional roles: UI/UX, business analysts, Software Architects. We need it for our own sanity. We need it and the business needs it, there's no shame in that.

That sounds more like Feature Driven Development, which fixes scope and flexes time as an approach to agile software development.

Exactly. It is very common for customers, whether internal or external, to not fully understand their own requirements. It is not easy to imagine the details of something they have not seen before.. So if you are not building a trivial variant of some standard existing software, you need to include a learning process along the way.

@@ComradeOgilvy1984 Yep. And there's rarely any "budget" for that learning process.

I've run into this problem multiple times. The end user doesn't know what they want. They have a general idea but haven't thought through to completion what it is they want built. That's where agile requirements come in. As developers we make our best guess what the customer wants and build a prototype quickly. Get feedback and iterate again. Software iterations can drive out ambiguities in requirements. You don't have to determine everything up front. Ambiguities can open up opportunities that you couldn't see earlier in the process. Ambiguity isn't always a bad thing.

@@deanschulze3129 Exactly. If you press a customer for the details of what they want, they will tend to try to explain in terms of standard things that already exist, regardless of how mediocre the standard things are for the problem on hand. Now, that is not necessarily a terrible mistake as a beginning point if you plan on improving iteratively, but it points to why trying to make detailed requirements early tends to be counterproductive -- you exhaust your customers and stakeholders early, and they quickly get frustrated when things do not turn out well. Better to start off with the mindset that early deliveries will be BOTH good and mediocre, but improvement is inevitable, and THEN it makes sense to press for detailed feedback and guidance.

Don't leave QA out of that approach you are working on. Most of the problems in the industry could be improved by intelligent QA teams focusing on set-based methods of testing - i.e. develop tests that will work REGARDLESS of the implementation or language or project methodology or team structure. Do that, and you have a control gate against the problems with code, stakeholders, processes, bad design, etc. QA is the most important part of the process, and TDD is not the answer (sadly, I wish it was).

The last step would be to stop calling any methodology (even XP) "real agile" :)

Yeah it's basically the SEO market for management.

Joke's on the people paying so-called "gurus", who never wrote a line of code in their lives, to teach them about Software Development Lifecycle...

Yes, I think that there is a kind of "new speak" around waterfall thinking that attempts to hide it. Not sure if it is on purpose, but it certainly exists. Most companies that I work with still divide dev into a series of steps or stages, with very little iteration or feedback between them. Whatever you call it, that's a waterfall!

It's engrained in humanity that we think we can design things better than we actually can. Some people realize this and understand agile, but most don't "The curious task of economics is to demonstrate to men how little they really know about what they imagine they can design" -FA Hayek

This "law" treats people as non-sentient, pretty much.

@@piotrkozbial8753 The system doesn't really allow and incentivise individualism, virtually by definition.

Haha, a lot longer of course. Industry average is $50 per line of code. NASA pays $1,000 per line of code. That's the cost if you want defect free code.

It's all about title-case Agile, that is a simulacrum of actually being agile. That enterprise-type Agile camouflages command and control under some activities that mimic flexibility by giving minimal self-organization and ownership practices to employees.

"I feel something has happened where we" --> A lack of qualified engineers, allowed management to entertain the notion, that those skills could be replaced by process. Agile makes that promise. Not skilled in the SCIENCE of estimation? No problem, use points. Not skilled in grasping requirements? No problem, use use cases and cycles. Now, the industry is overrun with "developers" instead of engineers, and we still have ZERO empirical evidence, that most agile methods, ACTUALLY meet the claims of their proponents.

What you described sounds like 'agile ', and by that, I don't mean a methodology, but more of a principled approach based on circumstances

@@closeredge5198 no, that's common sense.

@piotrd.4850 and agile principles DONT include common sense ideas ( empiricism, inspect and adapt, collaboration etc) ???

Agile is for one-pizza-team internal organisation. It is NOT Project Management methodic, much less PRODUCT management.

I'm am with you on this. 40 years on software projects and it's black and white. Early waterfall projects in my career were successful, latter day Agile projects are truly awful. I feel sorry for young developers that haven't known anything but Agile, they have no clue there's a better way.

When end users won't do the work to create good requirements up front then developers can use software iterations to hone in on what the requirements should be. Get feedback and iterate again. This approach may not be ideal but it works.

I think that’s why people are asking for waterfall to return. It’s not that they wouldn’t rather be agile, it’s that they want the people at the upper tiers of the waterfall to have some accountability that is missing from the fake-agile waterfall.

Also unlike fake-agile waterfall, traditional waterfall is quite a lot more empirical and iterative. You build scale models of your structures and test them in wind tunnels and wave tanks and the like, then go back and refine them before passing the design down the waterfall and build it for real.

I still remember the time some of the CS capstone students complained to the faculty that the structure of the capstone class enforced a waterfall development method since the first deliverable was a requirements doc, the next deliverable was a risk analysis, etc.. They were not happy about that but they also didn't have much of a retort.

No, waterfall is terrible. In the paper that describes it, the author wrote to not practice this.

Sadly this kind of teaching is still happening, usually from people who have never built software for real.

What the teacher meant is your way wouldn't scale, but you have to learn a scalable methodology even though a school project doesn't need it, because in the real world you will need it.

@@_Mentat that's funny.... I talk about being at school (40 years ago) and you assume I'm still there or, at least, only just left. :)

@@edgeeffect Nothing in what I wrote implied you are currently or were recently at school.

I certainly think that's a factor, but the accounting practices and budgeting practices are just another facet of the same overly naive approach to, in this case, business. This is the bureaucratic response. I think it may be possible to get away with such inefficient, "distanced from reality" approaches for things that aren't exploratory and creative (like software), but even for those things it makes everything slower and less efficient. For exploratory and creative problem solving disciplines, like SW dev, it is death. I don't know of any great SW that was built this way. Read the "Mythical Man Month" (Fred Brooks saying the same things in the 1970s, or "Rapid Development" (Steve McConnell saying the same things in the 1990's). This bureaucratic approach is naive and completely misunderstands what SW dev really is.

Nope! Agile is "I think this is the right answer, but it may be wrong, how can we find out?" - which is also how science works! Waterfall is "If I think really hard I can get the answer right first time" which is how nothing ever works.

@@ContinuousDelivery nope. I said the foundation is organized with waterfall. The other %95 is agile. Unless you subscribe to start coding and then we'll tell you what we want. Retrofitting or planning the foundation after the fact is how kids plan

Sorry, but that is simply untrue, I worked on several projects that were run without there being any iteration, in fact in my experience that *is* the norm for waterfall projects. Structurally it is quite difficult to avoid. If you spent 3 months in analysis and 4 months in design, and then a developer says "this is wrong" what is the mechanism to correct the analysis or design? If you spent 6 months building the system and then during testing, find that the architecture is so bad that it makes the system too slow to use, again, what is the mechanism defined in most Waterfall projects to correct this, without redoing the whole waterfall. All of these are real world examples, from projects that I have seen myself!

@@ContinuousDelivery Well, that only means that your experience has been bullshit

Well said,they sell lies and yellow stickers to the wall.

Yes, sorry to say that is often how waterfall looks 🙃

it doesn't matter what system you use

Not true. We sign a contract with the customer before development starts. It's extremely rare for the customer to want changes, because with our help they correctly specify their requirements upfront.

Things actually work better this way in embedded. Agree, for pure software however.

Agile evangelists on the other hand promote concept, that 0% CAN be known or designed, so let's just figure everything out on the way.

Exactly

....as result, it creates permament 'crisis mode' and discourages long term thinking and investment.

“Lazy” management? More like micromanagement on steroids with unclear expectations and a lot of breathing down your neck.

Exactly, it means management can abdicate and not learn the software. They say you self-organize and I'll just count the story points.

Exactly. I am amazed how everybody is blaming waterfall but it's SCRUM which rigidly prescribes 2-week sprints

@@errrzarrr Exactly. For 'actual' development, two weeks is easily not enough, especially considering all the time wasted in "daily scrum" and associated BS..

There is not such a thing as accurate predictions. That is why they are called estimations, and not deadlines.

Unfortunately the prediction (estimate) always seems to morph into a deadline.

@@kevinmcnamee6006 nope. Usually it's fixed deadline, fluid sopce and "make it fit" like in Pentagon Wars.

Product needs to be a part of R&D. You know the date customer wants ‘something ‘ , so set a target date, and work closely with the team to build to the most valuable things first

Lol

Absolutely! The thing I wonder about is how we managed to allow ourselves, as an industry, to fall into this bucket. We don't have "Fixed cost lawyers" or "Fixed cost medical advice" or "Fixed cost shopping" or "Fixed cost business decisions", or "fixed cost marketing campaigns". I suppose we have crazy people attempting all of these things, but the reality is that lots of stuff doesn't work on the basis of being predictable. Why do so many orgs attempt to work on the basis that software is predictable, when it so clearly isn't? People have been trying, and failing, to treat it as a predictable thing since at least the 1970's, maybe it's worth trying something different by now? 🤣

In all the discussions about agile and waterfall, I think your comment hits the mark closest. It's belief vs empirical evidence, assumption vs zero assumption and trial and error, something like that. The synthesis between the two is common sense, that's my experience that gets the job done. Some assumptions need to be made, some kind of frame of reference or else the project spins so far out of control it tries to solve world problems. Too much meaningless trial and error gets you nowhere either.

Thank you for this. It's often debated as if software engineer is done in a vacuum, through a process piloted by an army of Kent Becks experience level developers

In most places, Jira is not even configured properly.

Nothing genuinely new is likely to succeed without iterations. There were smarter, better educated, better funded engineers trying to build an airplane, when the Wright brothers won the race. The Wright brothers were simply more methodical about incrementally building towards their goal and learning along the way. They saw that building simple gliders that flew a little were a practical necessity, and there was a lot to learn to even get that to work.

Hey, there's plenty of non-suits that doesn't understand this either. I've got multiple 45 yo senior architects at my current client who doesn't understand any of this. Every single suggestion they make is a nightmare to build and maintain long term. And they've got final say because they're architects.

​@@FudgeYeahLinusLAN Hey, I feel you. I experienced the heaven of working for an actual agile software company which turned into complete hell when we were acquired by a large waterfall company.

@@FudgeYeahLinusLAN A lot of architects reached that position for being smart and hardworking. But smart and hardworking does not always mean wise. In fact, it can mean they are very afraid of revealing that there are things they do not understand, which is the opposite of wisdom in an ambiguous situation. Many ambiguities cannot be resolved by simply waterfalling harder, and the all that bad design work becomes a sunk cost albatross.

@@ComradeOgilvy1984 - I don't think the Wright Brothers is a good analogy for software development. They had to create the field of aerodynamics while they were creating powered flight. They created the first wind tunnel. They did a lot of work on internal combustion engines getting a high power to weight ratio. They had their own engine builder. That would be like developers having to create their own language and compiler while they were creating their application.

Exactly

I don't really agree. I don't think it is a "mix of agile and waterfall" I think it is simply "waterfall in disguise". Agile means we can change, easily, quickly, waterfall means we can't, I don't think it is possible to mix them.

@@ContinuousDelivery what do you mean with "... change easyly, quickly" wenn it comes to system architecture ? Are you talking about a lean myth ?

Have you seen TDD in the wild? :D Otherwise, I agree.

Even reading your comment I see that the problem is not with a concept, but with a very wrong way the concept was understood and adopted. The fact that you pretty much equal Scrum and Agile (leave alone title-cased "agile") shows that there is actually little understanding of what agile is and what Scrum is. Still, even I am not a fan of Scrum anymore, the fact that Scrum gives power to PO and takes it away from the team sounds like a big misconception you have. It looks like your team has lost the whole idea of self-organizing team. If PO tells team what to do not listening to them, then it looks like your team's Scrum is just another example of dailies-review-retro-planning-sprints, not focus-courage-commitment-openness-respect and inspection-adaptation-transparency. Scrum should really be reduced to three pillars and five values. Events and roles should be dumped as these commonly shift focus from what actually matters.

@@archi-mendel Thanks for your response. It may surprise you to learn that I am a fully qualified Scrum Master. I know the process and know it doesn't work. Even on the SM course I asked the killer questions and got no answer. I asked, what does QA do while the devs are coding? What do the devs do while QA is testing? No real answers, just be idle it seems. We have a doc writer who gets a couple of hours of work per 2 wk sprint. Middle management asks for more people and senior management says we can see your engineers are not busy; so no more resources given. As for "self-organization" - the Scrum Guide is being followed to the letter, right down to how long each meeting should last; senior managers would allow deviation, but there are three layers of management between them and us. Our code base is vast and ancient. Some of it dates back to the 1980s. It runs at thousands of sensitive institutions. It is deeply intrusive; almost like delivering a replacement operating system. Really you need 20 years experience on it _as an engineer_ to even say something sensible about it. The size of our market footprint gives us a guaranteed income and lets nonsense take hold and the recently arrived Agile fans wave their kanbans and backlogs and look like they are delivering. But nothing new has been created since they arrived. I have never dared point out to senior management it's all smoke and mirrors. The experienced engineers are leaving in disgust but no one mentions the enormous staff turnover.

@@_Mentat define the fully-qualified SM please? It takes couple months to complete Python course and get the certificate, does this make you a fully qualified software engineer? I don't think so. So, why would some courses and a certificate make you a fully-qualified SM? A few years ago, I've read through Scrum Guide couple times and spent couple months practicing Scrum. This was enough for me to pass PSMII certification with not a single class taken. Did this make me fully-qualified agilist - no, definitely not. If management tells the team if they can or cannot hire more people to their team, then the team is not self-organizing. If the business doesn't allow the team to decide on the length of the meetings, then the team is not self-organizing. Your team follows events, but it doesn't looks to me that your team and your organization live the Scrum values. So, nope, you are not following Scrum Guide to the letter. The sole fact that you're talking about meetings length but say nothing about the ways you try to enable transparency, inspection and adaptation, and say nothing about focus, courage, commitment, respect and openness, tells me that you're not following Scrum. And these 2 parts + self-organization are the only things that can be considered agile thinking in Scrum. Your trainers are most probably bad at what they do. As of QA and other team members that may be struggling not having work provided to them for part of the sprint - they should be self-organizing to find the useful work. And there is always quite a lot of the work team needs to do to maintain their technical solution that is not a part of the sprint goal. If Scrum is not fitting your needs, why do you use it? For me it looks like you've got Scrum certification but you don't actually understand what it mean to be agile (yes, sentence-case). Scrum != agile (again, sentence-case). Scrum can be a choice of the team at some point of their agile journey if it fits their needs but the team should deviate from Scrum as soon as they find something in it that doesn't work for them. There is a lot in Scrum that actually prevents teams from being agile, but what you have described is not part of this. It's the fact that your organization is not agile and doesn't even understand why would you want to be agile that prevents you from getting any value from Scrum. Overall, your "fully-qualified" agilist journey will start at the point when you will realize that "Agile" != "agile".

@@_Mentat I'm also a certified Scrum Master and certified Product Owner. You are openly stating falsehoods. Perhaps the process you've built at your organization doesn't work, but it is patently false to say Scrum doesn't work. I helped a team go from buggy releases that were always late to having accurate long term forecasts, releasable bug-free code multiple sprints in a row, reduced team member stress, and the happiest client we ever had... all by building a process that most closely worked within the Scrum framework as the company had ever tried. It does work. It's not perfect. And its biggest flaws are people problems. But it sounds like you have a lot of unlearning to do because you're simply stating falsehoods that demonstrate you don't understand what Scrum even is.

@@davetoms1 long-term forecasting is not agile ;)

Because this is just a cut scene from an engineering room episode

Well in a really agile org iterate through all of these things repeatedly. A bit of research, a bit of UI design, some SW dev, some releasing, and so on. Actually, I think treating UI design as separate from dev is a pretty strong anti-pattern, but you get the idea.

So it's all about interactive, incremental short waterfall cycles ?

@@jlou888 - Waterfall has always had feedback and iterations, but they are considerably longer than typical agile iterations would be. Waterfall was really a straw man setup by Winston Royce to illustrate a point. I've never worked on a classic waterfall project (though I've been told they actually exist). I have worked on a lot of projects that were code-and-fix or that had some big design up front. I think the key difference between BDUF and being agile is that with agile your up front planning and design is minimal so it is easy to leave it behind. If people put a lot of effort up front it's more difficult to leave it behind and change what you will deliver.

Agreed: Successful: Google, Amazon, Tesla, Apple, SpaceX, Microsoft (read Rapid Development by Steve McConnell)... Failed: "TAURUS Electronic trading platform" £75m over budget before cancellation "FAA Advanced Automation System" $3-6bn over budget before cancellation "NHS Connecting for Health Project" £12bn over budget before cancellation. Lots more here: en.wikipedia.org/wiki/List_of_failed_and_overbudget_custom_software_projects

Waterfall is really just sequential stages: plan first, then develop, then test, then maintain. Agile is develop + plan + test together and then throw in maintain with the other three when the project is released into the wild. Waterfall is appropriate for projects that are intended not to change (much): medical devices, automotive, etc. Agile makes more sense for general purpose stuff like Desktop, Web, Mobile, or even library development where you don’t have a clear idea of how something is going to be used and things are subject to change. With those definitions out of the way, Kent Beck’s statement absolutely makes sense for the latter category.

@@mecanuktutorials6476 not having a clear idea and things being subject to change are fundamental properties of doing business. If you think you have it all figured out and nothing will change then a competitor will inevitably come and eat your lunch. Not even state monopolies are free from this, the public policy that keep them in power are also subject to change. I’m in automotive myself, if car markets stopped changing I’d be the first to know. Waterfall is a good choice for construction and manufacturing where the actual build step happens in the real world and a single production run costs millions, if not billions. Cars, planes, skyscrapers, space telescopes, etc. Then you are simply forced to work in open loop control mode because you don’t get second chances. Using waterfall in software is essentially to pretend that running the compiler even once costs millions of dollars. Using waterfall for software evidently works for the same reason that waterfall works for skyscrapers and space ships. It’s just sub-optimal for software. You need a better argument for companies to actually use agile than “sub-optimal”.