> It is my belief that Agile arrived because it's the best way to work when managers, "architects", and programmers who cannot estimate, cannot communicate well, and don't have a good idea what are they they doing. After all, there is no point in daily standup if everyone can recognize they are stuck and ask for help; and there is no point in group planning if there is someone who knows the system and has a good idea about each team member's capabilities.

You're right. PRIDE can't make a silk purse out of the sow's ear of unclear requirements, poor communication, and people not knowing what's needed. But... neither can Agile! You have to hire people with the requisite skills. You wouldn't hire someone who couldn't write a line of code as a programmer, would you? So why hire someone who can't communicate as a systems analyst or manager? Agile methods at best might converge on an adequate solution via random walk or gradient descent, refactoring and rewriting code in a manner that annoys the user less and less. So, granted, it may indeed be the best way to produce Hamlet when all you have is ten thousand monkeys with typewriters. But if Hamlet is what you wanted, why use the monkeys and typewriters in the first place? Better to build the right thing, the right way and that's what PRIDE is designed to do.

> That problem is not going to disappear if you are moving into bureaucracy-heavy development process. OK, you've removed programmers from driving seat.. so who is going to be sitting there now? Some sort of "system architect", someone who does not program themselves, but somehow knows about all possible problems and can design great systems? What will happen to all the plans when one discovers that a database that architect mandated is full of bugs when used in the particular mode the project needs? Or the object store cannot perform fast enough and it's time to switch to distributed architecture?

Back in the day, there used to be a profession known as the systems analyst. It was their job to analyze the information needs of the business, produce a report on what the current state of things was and what the units of the business actually needed and could provide in terms of information, and propose a design for an information system that would ensure that the right workers had the right information at the right time. An information system is not software and it does not necessarily run on a computer; any such system could plausibly be designed as a manual process that uses forms and other paperwork. It's just much more efficient to use computers when they're available, so information systems incorporate computers and software to greatly reduce tedium and increase productivity.

The systems analyst does not "know about all possible problems". Rather, they ask the people in the business what their specific problems are and design a system to solve them. Systems analysts also do not make decisions like which DBMS to use. That is a concrete concern; and information systems design happens in the abstract. (Tim Bryce says that systems analysis is "logical" whereas programming is "physical"[0]. Same thing.) Systems analysts collaborate with programmers and DBAs to determine what's technically feasible, and they make adjustments accordingly depending on the feedback from these more technical personnel.

Systems analysis is kind of a forgotten field nowadays. Rather, sloppy thinking in business has promoted the idea of the genius programmer who can solve business problems through writing lots of code. As a result, programmers have been promoted to systems analysis roles, and the result has been a disaster. Systems analysis requires a big-picture perspective with relatively little focus on technical detail. Understanding the business as a whole, and the information flows of that business in the abstract, is paramount. It also takes people skills: you have to know the right questions to ask, and when "the users don't really know what they want" (a common complaint of programmers, one which they believe negates the whole point or need for requirements elicitation), you have to figure that out as well. For example, a salesperson may request an itemized list of everything in inventory, when what they actually want is an aggregated breakdown of inventory by product category. So then you have to drill down and ask the sales team, for what purpose do you intend to use this information? And based on that, propose a better solution. Assigning a programmer to this task will result in disaster because the programmer won't be a "people person". They won't know which questions to ask, nor how to interpret the answers, because they don't think in terms of the business but rather in terms of technology. There's a reason why systems analysis was historically separate from programming.

Systems analysis should take up the bulk of an IS implementation project. The creators of PRIDE say that ideally, 60% of the project's time and budget should be taken up by systems analysis and only 15% by programming; furthermore, that there should be more analysts than programmers on a project. This is because once you've really nailed down and defined what the information requirements of the business are and how that information should flow through divisions, departments, etc., programming becomes just a straightforward act of translating those flows into code. (Back in the day, Tim Bryce wrote an essay called "Theory P" in which he described programmers as "just translators", which rustled a lot of programmer jimmies but was ultimately correct: under PRIDE, there is literally nothing else for programmers to do!) It's the analysis that's the hard part: engaging the relevant personnel in round after round of discussions and stepwise refinement of the original system or subsystem design until all can come to agreement that the design would provide the right information at the right time to the right people. Only then does coding begin.

The Agile way is just the opposite: programmers take a first stab at implementing a system in code, put it in front of users, identify the ways the users get frustrated, go back to the code and make a guess at changes that need to be made to better satisfy the users, roll that out to the users, repeat ad nauseam. It's all guesswork, stabbing in the dark. Very little thought is given to the needs of the business or how information is supposed to flow through the business to get where it needs to go. This is literally what Milt Bryce described as the "traditional" method of software development in 1982[1]. Agile came first, and it sucked!

> I don't think PRIDE can work on new & innovative projects.. Sure, if your org is specializing in building identical e-commerce websites, or doing one ERP system after another, then by the 3rd time you'll know enough to be able to plan most of the thing and PRIDE maybe can make sense. But this niche is shrinking all the time - if there is really a need for many identical software projects, someone will make a SaaS and most customers will flock to it because of much lower price.

I think many companies vastly overestimate the amount of innovation they need to do, and specifically the amount of technical innovation they need -- most businesses need more innovative systems designs, not more innovative programming techniques. Theoretically, 99% of businesses could handle all their information systems through mainframes running COBOL on green screens. Not that they should -- modern programming techniques have made programmers' lives easier and more productive after all[2] -- but they most certainly could.

From a software standpoint, most businesses need CRUD operations, data handling, reports, and analysis -- and not much else. The key is to identify what the informational needs of the business are before you commit to a technical path. The company I worked at that abandoned their Agile transformation was a very large, old, established company that was attempting to cosplay as a hip, innovative tech startup. They took out an entire floor of a WeWork. Very "how do you do, fellow young people?" moves. Then the pandemic hit, and then the ZIRP ended, and they started to take a long hard look at the expenses incurred vs. the actual benefits of these moves, and started rolling them back. What they really needed in the end, was fresh leads routed to salespeople, and/or existing customers routed to support personnel. And you're right -- a lot of this is stuff they could have done with SaaS like Salesforce.

But here's the thing: PRIDE is for building information systems -- not just software. It can help you identify what you need to build and what you can just buy to implement a given system. It probably would've saved this company quite a bit of time, money, and developer effort to have done more upfront systems analysis and identified the parts that could just be done with an off-the-shelf solution (as well as the parts that actually did need bespoke coding). But they were caught in the microservices, cloud, and Agile hypecycle, and those were the hammers with which they were going to drive the information-systems screws into place.

[0] https://www.linkedin.com/pulse/software-hard-tim-bryce/

[1] https://www.youtube.com/watch?app=desktop&v=SoidPevZ7zs&t=47...

[2] Maybe the percentage of time spent programming should be further reduced in light of this? Maybe to 10%? More research is needed here.