How much do you think it was an artifact of the time? Agile relies on it being fast/cheap/easy to ship and deploy incremental changes. I have a hard time believing that to be the case in the 80s. When planning and designing on paper is cheap in comparison, it makes sense to me that is the development method people used.
> How much do you think it was an artifact of the time?
I was a software engineer in the 90s at a small company (15 people) doing simulation development for the UK Ministry of Defence. We had two distinct software development processes, which were waterfall and a form of rapid development known as the Dynamic Software Development Method (DSDM). (I threw away the manuals years ago so can’t give more info).
The company directors came from an aerospace background so had a very strong software quality focus. Many of our contracts specified waterfall and our project artefacts reflected that – user requirements docs, system requirements, architectural design, detailed design, integration test plans, system tests, acceptance tests, etc etc. Coding happened somewhere in the middle. It did work, sort of, in situations where the customers knew what they wanted, and we mutually understood it. Which was quite often the case, for our regular customers on projects that were extending existing systems.
We trialled DSDM for projects where the customer said ‘prototype’ and I liked it. It lacked the onerous agile / scrum boilerplate and IIRC was based around loosely specified timeboxes and relied on having ‘intelligent customers’ who were prepared to be flexible in terms of what they got at the end.
The need for DSDM was motivated by a project that failed badly (not with the MOD) because the customers said ‘here are our requirements for this prototype system, don’t come back until you have finished and tested it’. Needless to say the result wasn’t what they expected, even though all of the requirements had been, on paper, met.
But for any development where specific technical outcomes were necessary (e.g. a maths module), waterfall would usually be used.
I got a course at Oracle on DSDM RAD (rapid application development) and worked on a project with it. The 4GL tooling used at Oracle were no good fit, but back then also Oracle was moving up to 3GL tools like JDeveloper. And they thought using RAD was good fit.
Key what I remember was time boxing. And much less religious stance than Agile. But back then it was normal to have different people doing functional designs, technical designs, database design (also in two levels) and business process design of sorts. I guess it took a while for these people to realise they had to be Agile digital transformers.
And I guess it also did not help the DSDM also certified people on the waterfall methodology.
I think it was more about the corporate culture which dictated that people had a plan and stick to it.
It's still the case in many trades. You don't build a house or a bridge the Agile way for instance.
IMHO Agile got a lot more prevalent because the planning phase became more and more onerous to have any reliability, and management was tired of paying upfront for it. I steady they could get a more regular billing (in particular when dealing with consulting companies) with reports of stuff allegedly shipped, instead of six months of "we're planning very hard, just trust us". Whether the end result matched what they needed/wanted to build being another story.
I know many companies that had an official Waterfall cycle, while actually working on something more granularly shipped with many phases of prototyping. And they didn't move to Agile either, just stopped calling their process anything and went on doing whatever felt right.
I think it was an artifact of applying physical construction project concepts to building software.
If you're building a house, or something bigger, you don't just start nailing lumber together. You have a blueprint. Pretty detailed, and it uses industry-standard terms and markup. Any builder can take it and use it to construct the building. It has the dimensions and specifications for the foundation and all the rooms. It has considered where the rooms are, which walls are load bearing, where the staircases and HVAC and plumbing and electrical runs are, where the windows and doors are, pretty much everything. An engineer has signed off on the overall design as being safe and meeting all the applicable codes. You can order a list of supplies based on this plan and you'll be within a few percent of what you actually use.
Some small changes were allowed. You could change finish details like what style of cabinets or trim or door knobs would be used. But you could not really approach the builder once the framing was complete and say actually I wanted the living room over there and the bedrooms over here and also I want to add a third storey. You also didn't build one bedroom, and then based on that experience extrapolate the design for the next one, and then apply that to building the kitchen, and so on. It was all done up front.
People, especially people who were used to managing physical projects, thought that with the same level of planning, and the same approach to management, the same results could be achieved in software projects.
At that time the waterfall model method was one solution to the problem of software quality. Other methods hadn't yet been developed (or at least not become well known yet), and waterfall was in use by the industry (not everywhere though - re sibling comment). The customer I mentioned was huge and lots of companies in lots of European countries, and overseas too had development contracts which demanded this process to be used. And the results were actually good, even though the process was heavy. That didn't mean that it couldn't be improved on, and that did happen later, with more agile-like (though not "Agile") methods modifying the approach.
I find agile passive aggressive because the consensus is built under duress. I prefer a well reasoned approach. I can understand agile process in between waterfall milestones.
I can even support an agile process to create waterfall process.
Developers are still constrained by process, and it's their fault.
In every single company I have worked, the process always took priority. It's made even worse where you have ISO 9001 compliance where every god damn thing in the company is locked into a "process." Process over people, period. Coporo-managers can't get it out of their head.
When all you have ever done is "the process" it looks perfectly sane. To teams that can produce a POC and basically get to market on their own domain knowledge, it looks ridiculous. Making developers wait for requirements instead of inventing them on the fly is incredibly slow and smothers nearly all innovation.
Why risk making your product look like your convoluted communication and political structures? The entire point of agile was lost on the influx of bodies to the industry.
Form a "skunk works" team and shield them. Make a big show of how their success came despite having zero fucking process. Jira is for maintenance.
> In every single company I have worked, the process always took priority.
If process (or freedom from process) is important to you, you need to make it a priority when you're interviewing. May depend on what industry you work in, of course, some industries don't have any cowboys.
That said, I like my cowboy jobs with a little bit of process. What's deployed in production should be reflected in source control, but I'm not a stickler for which comes first. A change notification should be posted before production is changed, but if you have separate push and load steps, you can push before you notify (if pushing takes a while, it's good pipelining to use the push time to compose your change notice). Changelogs usually shouldn't be 'bugfixes' or 'latest', but 'fixing' is appropriate for a close in time followup. That's process, even if an ISO compliance officer would lose their mind.
That's why it's your fault, because you won't make decisions. You feel like there are rules and guardrails constraining you and bringing order to society but it is not so. If you envision the reality and live it, then it will manifest. Some people thinks this means being forceful and demanding. Just the opposite.
Then again, I doubt the company has a reward structure in place that even makes the mental energy worth expending.
If you aren't on the way up, then you are on the way out.
