3 ms·

> Isn't this what many reasonably run companies do anyway? I love how the most basic of practices in any engineering field is depicted as a groundbreaking epip

> Isn't this what many reasonably run companies do anyway? I love how the most basic of practices in any engineering field is depicted as a groundbreaking epiphany in the software industry.

DocTomoe 4y ago
Software Engineering is still in the stage of early industrialism - when James Watt built his steam engine, or Carl Benz built his car, they did not have specification documents. They tinkered and made it work, moving around assemblies until everything fit, then improved on the design. Essentially, they were doing some form of 'agile': small teams (to the point of only one), no specifications, high turnover. Today, this approach is unthinkable in mechanical engineering, because bad designs are lethal. The software engineering environment is special because when it started out, everyone thought of it as just another branch of engineering, so they applied standard industrial processes onto it - and that did not work well, what worked for building hydraulic presses did not translate well to writing software. SE needed to "learn" how to tinker and experiment on mid-sized projects first, and now they are in an early-industrial-age phase (and call it 'agile'). Eventually, SE will return to something more organized, something more reliable - after all, we are learning that bad design choices can be lethal. We are seeing the first steps today, trying to capture agility with frameworks, with dedicated test methodologies, ... Naturally, this will cause frustration with the tinkerers, and it will take time. And while some aspects will resemble mechanical engineering processes, some things will be completely new and untranslatable to other engineering disciplines.
- rileyphone 4y ago
  We've been waiting for years for software to become something more organized and reliable. It will take a rethinking of the fundamentals to get there IMO, along the lines of Brad Cox's thinking in [0]. Object-oriented programming was a revelation for a period, but overhype and overselling has made it non grata to a lot of developers. Now we wonder, what the next iteration of progress will be? [0] https://www.researchgate.net/profile/Brad-Cox-2/publication/3246772_Planning_the_software_industrial_revolution/links/540f00220cf2df04e759dae8/Planning-the-software-industrial-revolution.pdf?origin=publication_detail https://www.researchgate.net/profile/Brad-Cox-2/publication/...
CipherThrowaway 4y ago
Is this even true? Applying engineering project management and methodology to software was the default approach historically. This is essentially the waterfall/BDUF that "agile" was reacting to. The OP is just content marketing for some proofreading software. No one actually thinks this stuff is an epiphany unless they are completely unfamiliar with the history of the field.
pif 4y ago
It's not the industry: it's the customers! With hardware (be it a bridge, a car, a pair of jeans) customers know and accept that no modification is possible once the product is accepted. With software, customers have grown acquainted to the reality that software will evolve to fit their changing needs. Later, this became hoping for a software that can anticipate their needs. Finally, it perversely morphed into expecting a software that precede them being aware of their own needs.

> Isn't this what many reasonably run companies do anyway? I love how the most basic of practices in any engineering field is depicted as a groundbreaking epiphany in the software industry.

DocTomoe 4y ago

Software Engineering is still in the stage of early industrialism - when James Watt built his steam engine, or Carl Benz built his car, they did not have specification documents. They tinkered and made it work, moving around assemblies until everything fit, then improved on the design. Essentially, they were doing some form of 'agile': small teams (to the point of only one), no specifications, high turnover. Today, this approach is unthinkable in mechanical engineering, because bad designs are lethal. The software engineering environment is special because when it started out, everyone thought of it as just another branch of engineering, so they applied standard industrial processes onto it - and that did not work well, what worked for building hydraulic presses did not translate well to writing software. SE needed to "learn" how to tinker and experiment on mid-sized projects first, and now they are in an early-industrial-age phase (and call it 'agile'). Eventually, SE will return to something more organized, something more reliable - after all, we are learning that bad design choices can be lethal. We are seeing the first steps today, trying to capture agility with frameworks, with dedicated test methodologies, ... Naturally, this will cause frustration with the tinkerers, and it will take time. And while some aspects will resemble mechanical engineering processes, some things will be completely new and untranslatable to other engineering disciplines.

rileyphone 4y ago
We've been waiting for years for software to become something more organized and reliable. It will take a rethinking of the fundamentals to get there IMO, along the lines of Brad Cox's thinking in [0]. Object-oriented programming was a revelation for a period, but overhype and overselling has made it non grata to a lot of developers. Now we wonder, what the next iteration of progress will be? [0] https://www.researchgate.net/profile/Brad-Cox-2/publication/3246772_Planning_the_software_industrial_revolution/links/540f00220cf2df04e759dae8/Planning-the-software-industrial-revolution.pdf?origin=publication_detail https://www.researchgate.net/profile/Brad-Cox-2/publication/...

CipherThrowaway 4y ago

Is this even true? Applying engineering project management and methodology to software was the default approach historically. This is essentially the waterfall/BDUF that "agile" was reacting to. The OP is just content marketing for some proofreading software. No one actually thinks this stuff is an epiphany unless they are completely unfamiliar with the history of the field.

pif 4y ago

It's not the industry: it's the customers! With hardware (be it a bridge, a car, a pair of jeans) customers know and accept that no modification is possible once the product is accepted. With software, customers have grown acquainted to the reality that software will evolve to fit their changing needs. Later, this became hoping for a software that can anticipate their needs. Finally, it perversely morphed into expecting a software that precede them being aware of their own needs.