3 ms·

In 1971, M. Bryce and Associates marketed PRIDE, the first commercial software methodology for general business use. It was originally an entirely manual proces

In 1971, M. Bryce and Associates marketed PRIDE, the first commercial software methodology for general business use. It was originally an entirely manual process using paper forms, but it was already far more comprehensive than anything called a "methodology" we use today. For example, in PRIDE, every artifact of the systems design and implementation process -- each high-level requirement, each software module, each database table and column, and more -- is assigned a tracking number and extensively documented as to its purpose in a unified knowledge repository. This was decades before Git or JIRA, and at first it was all done by hand, but not for long. In the 80s, they marketed PRIDE/ASDM, which combines PRIDE with Automated Systems Design Methodology, a suite of system design tools written in COBOL for mainframes. Far from being mere diagramming tools, they assisted in all aspects of an information systems design from initial requirements down through coding and database management. A key component of ASDM was the Information Resource Manager (IRM), a searchable central database of all of the information artifacts described above along with their documentation. Another component was Automated Instructional Materials (AIM), the online documentation facility, which not only provided instructions on how to use the system, it also provided step-by-step directions (called "playscripts" in PRIDE-speak) for each member of the development team to follow, in order to see a business system through from abstract design down to software implementation and deployment. Provided the directions were followed, it was next to impossible to screw up a system or subsystem implemented through PRIDE/ASDM. This level of comprehensiveness and clarity is the gold standard for business IS development. And it seems to be nearly lost to time.

theamk 2y ago
"every artifact of the systems design and implementation process [..] is assigned a tracking number and extensively documented", "it also provided step-by-step directions [...] for each member of the development team to follow" Maybe this made sense back in times of COBOL, but with the modern high-level languages this sounds like bureaucratic hell, the worst kind of micromanagement.
- bitwize 2y ago
  Well, what's happened in the years since is that programmers have been in the driver's seat when it comes to IS, and that's resulted in a lot of sloppy, disorganized thinking in the field. Programmers in general fancy themselves as artists and resist organization and discipline -- as true today as it was in the COBOL days -- so it's no surprise that a method based on improved process control seems like micromanagement. But that level of discipline is needed in order to do the work right. Ultimately it should come down to self-discipline. Unfortunately, IS has morphed into a programmer-centric field, which leads us to Agile, a family of methodologies by programmers for programmers. Agile mythology has it exactly backward: Agile is not the thing that saved us from waterfall. Agile was the "traditional" software development process PRIDE was created as a response to: start programming right away, deploy rough versions to production, and keep iterating with code changes until you have something that kind of, sort of works. Compared to this, PRIDE delivers improved productivity and quality, reduced costs, and reduced administrative overhead. I've never been on an on-time, under-budget Agile project, and one of my former employers basically aborted their entire Agile transformation. Once the industry has shaken off its Agile wine, especially as profitability becomes more important in the post-ZIRP economy, software development will look more like PRIDE than like anything we see today.
  - theamk 2y ago
    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. 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? 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.

theamk 2y ago

"every artifact of the systems design and implementation process [..] is assigned a tracking number and extensively documented", "it also provided step-by-step directions [...] for each member of the development team to follow" Maybe this made sense back in times of COBOL, but with the modern high-level languages this sounds like bureaucratic hell, the worst kind of micromanagement.

bitwize 2y ago
Well, what's happened in the years since is that programmers have been in the driver's seat when it comes to IS, and that's resulted in a lot of sloppy, disorganized thinking in the field. Programmers in general fancy themselves as artists and resist organization and discipline -- as true today as it was in the COBOL days -- so it's no surprise that a method based on improved process control seems like micromanagement. But that level of discipline is needed in order to do the work right. Ultimately it should come down to self-discipline. Unfortunately, IS has morphed into a programmer-centric field, which leads us to Agile, a family of methodologies by programmers for programmers. Agile mythology has it exactly backward: Agile is not the thing that saved us from waterfall. Agile was the "traditional" software development process PRIDE was created as a response to: start programming right away, deploy rough versions to production, and keep iterating with code changes until you have something that kind of, sort of works. Compared to this, PRIDE delivers improved productivity and quality, reduced costs, and reduced administrative overhead. I've never been on an on-time, under-budget Agile project, and one of my former employers basically aborted their entire Agile transformation. Once the industry has shaken off its Agile wine, especially as profitability becomes more important in the post-ZIRP economy, software development will look more like PRIDE than like anything we see today.
- theamk 2y ago
  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. 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? 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.