4 ms·

I think Brooks is still right and what author mentions is not one thing but a set of practices that became proven enough that became almost like a standard appr

by haddr 7y ago

I think Brooks is still right and what author mentions is not one thing but a set of practices that became proven enough that became almost like a standard approach in software development. And they provide some productivity gains if we compare how software was built 50 years ago. Yes, the difference is big but we forget that all those things were introduced incrementally and in the course of decades. So yes, together they make a huge difference but they haven’t appeared in one day.

rcthompson 7y ago
Git and Mercurial were both originally developed over the course of a month or so. If DVCS really results in an order-of-magnitude improvement (which do I find credible), then I think it qualifies as a silver bullet by Brook's definition.
- OrangeMango 7y ago
  Of all Git users, only an extremely small percentage use Git as a DVCS (Linux kernel, etc). GitHub is a centralized VCS. In fact, I think you could argue that the emergence of GitHub is a demonstration that DVCS is nearly useless for the vast majority of software development.
  - anticodon 7y ago
    I think you don't understand what makes centralized VCS different from distributed. GitHub is just another clone of the repo. For example, I can commit in my Git clone, can create a new branch, merge a branch, push it to the server, all without GitHub server being available. If GitHub would be down or closed tomorrow, this would not significantly affect my work on the repository. This wasn't possible using centralized VCSs.
    - OrangeMango 7y ago
      You can do all of this because Git repos are self-contained complete historical records. You could do this with a traditional VCS as long as you took frequent backups. Git is an improvement in this regard, but not a revolution. Furthermore, you are describing a workflow that is inconsistent from many "industry best practice" recommendations. If GitHub went down, a very large number of Git users would not be able to run tests or deploy their code to production - their CI/CD pipelines don't work without GitHub. Their historical record of issues goes away when GitHub goes down, etc.
      - anticodon 7y ago
        With traditional VCS, I would lose all the history and ability to work (to commit my changes, for example) if server goes down. And I understand that issues and CI/CD will also stop working, but neither of that is part of the VCS itself. I'm not aware of distributed issues (maybe FOSSIL) and CI/CD. Still it doesn't mean that GitHub makes Git centralized.
    - deleted 7y ago
      [deleted]
- AnimalMuppet 7y ago
  DVCS results in an order-of-magnitude improvement? In writing software? I highly doubt it. For that to even be possible, DVCS would have to take on the tasks that take 90% of your time as a programmer. I don't think it can.
  - samatman 7y ago
    To quibble, I've long been frustrated that we have no way to distinguish between natural and decimal orders of magnitude. I'm convinced the former is nearly always a more useful measure, but we're sort of stuck with the latter. Even so, no one prior to Git spent 50% of their time wrestling with the VCS, or solving problems caused by a lack of one.
the_af 7y ago
Agreed. There is still "no silver bullet", though experience has shown some practices that seem to be moderately successful. I think the author of this article is overselling almost every of these advances. Don't software projects still keep failing or being cancelled at an alarming rate, even when doing some or all of these improvements? And there's no compelling evidence that projects using, say, TDD, are significantly more successful, is there?
- rcthompson 7y ago
  I maintain an Emacs package[1] that focuses on user interaction and hooks deeply into the internals of Emacs in potentially fragile ways (e.g. it sometimes needs to actually inspect the call stack in order to determine the correct behavior). For a long time, I had no way to test it in an automated fashion because it was an interactive package, so each release required me to laboriously test its functionality to make sure I hadn't broken anything. Beyond just the time required for manual testing, the mere need for manual testing discouraged me from making releases in a timely fashion. The manual testing also meant that my package was only tested on a single Emacs version (i.e. whatever I was running at the time). Then I finally figured out how to simulate user interaction using Elisp[2], and used this to add a test suite to my package. My tests have caught a number of regressions, especially in older versions of Emacs that I no longer use but still want to support. In addition to being faster, development has been much easier and less stressful for me because I know I can experiment and rely on my test suite to catch almost any regression I introduce. And the stress factor is important, since this is an open source package that I maintain for free, and if it was too stressful, I would probably just stop working on it. Was adding tests to this project a 10x improvement? I don't know, but it sure felt qualitatively like a silver bullet to me. [1]: https://github.com/DarwinAwardWinner/ido-completing-read-plus https://github.com/DarwinAwardWinner/ido-completing-read-plu... [2]: https://github.com/DarwinAwardWinner/with-simulated-input https://github.com/DarwinAwardWinner/with-simulated-input
  - the_af 7y ago
    You have a point and automated tests are definitely a big deal. However, as Wikipedia summarizes about "No Silver Bullet": > "While Brooks insists that there is no one silver bullet, he believes that a series of innovations attacking essential complexity could lead to significant improvements." So I'd say your experience doesn't contradict his point. Automated testing is not an orders of magnitude improvement, and software projects continue to fail or be flawed at an alarming rate, but it definitely helps! (like Brooks also said of high-level languages).

by haddr 7y ago

rcthompson 7y ago

Git and Mercurial were both originally developed over the course of a month or so. If DVCS really results in an order-of-magnitude improvement (which do I find credible), then I think it qualifies as a silver bullet by Brook's definition.

OrangeMango 7y ago
Of all Git users, only an extremely small percentage use Git as a DVCS (Linux kernel, etc). GitHub is a centralized VCS. In fact, I think you could argue that the emergence of GitHub is a demonstration that DVCS is nearly useless for the vast majority of software development.
- anticodon 7y ago
  I think you don't understand what makes centralized VCS different from distributed. GitHub is just another clone of the repo. For example, I can commit in my Git clone, can create a new branch, merge a branch, push it to the server, all without GitHub server being available. If GitHub would be down or closed tomorrow, this would not significantly affect my work on the repository. This wasn't possible using centralized VCSs.
  - OrangeMango 7y ago
    You can do all of this because Git repos are self-contained complete historical records. You could do this with a traditional VCS as long as you took frequent backups. Git is an improvement in this regard, but not a revolution. Furthermore, you are describing a workflow that is inconsistent from many "industry best practice" recommendations. If GitHub went down, a very large number of Git users would not be able to run tests or deploy their code to production - their CI/CD pipelines don't work without GitHub. Their historical record of issues goes away when GitHub goes down, etc.
    - anticodon 7y ago
      With traditional VCS, I would lose all the history and ability to work (to commit my changes, for example) if server goes down. And I understand that issues and CI/CD will also stop working, but neither of that is part of the VCS itself. I'm not aware of distributed issues (maybe FOSSIL) and CI/CD. Still it doesn't mean that GitHub makes Git centralized.
  - deleted 7y ago
    [deleted]
AnimalMuppet 7y ago
DVCS results in an order-of-magnitude improvement? In writing software? I highly doubt it. For that to even be possible, DVCS would have to take on the tasks that take 90% of your time as a programmer. I don't think it can.
- samatman 7y ago
  To quibble, I've long been frustrated that we have no way to distinguish between natural and decimal orders of magnitude. I'm convinced the former is nearly always a more useful measure, but we're sort of stuck with the latter. Even so, no one prior to Git spent 50% of their time wrestling with the VCS, or solving problems caused by a lack of one.

the_af 7y ago

Agreed. There is still "no silver bullet", though experience has shown some practices that seem to be moderately successful. I think the author of this article is overselling almost every of these advances. Don't software projects still keep failing or being cancelled at an alarming rate, even when doing some or all of these improvements? And there's no compelling evidence that projects using, say, TDD, are significantly more successful, is there?

rcthompson 7y ago
I maintain an Emacs package[1] that focuses on user interaction and hooks deeply into the internals of Emacs in potentially fragile ways (e.g. it sometimes needs to actually inspect the call stack in order to determine the correct behavior). For a long time, I had no way to test it in an automated fashion because it was an interactive package, so each release required me to laboriously test its functionality to make sure I hadn't broken anything. Beyond just the time required for manual testing, the mere need for manual testing discouraged me from making releases in a timely fashion. The manual testing also meant that my package was only tested on a single Emacs version (i.e. whatever I was running at the time). Then I finally figured out how to simulate user interaction using Elisp[2], and used this to add a test suite to my package. My tests have caught a number of regressions, especially in older versions of Emacs that I no longer use but still want to support. In addition to being faster, development has been much easier and less stressful for me because I know I can experiment and rely on my test suite to catch almost any regression I introduce. And the stress factor is important, since this is an open source package that I maintain for free, and if it was too stressful, I would probably just stop working on it. Was adding tests to this project a 10x improvement? I don't know, but it sure felt qualitatively like a silver bullet to me. [1]: https://github.com/DarwinAwardWinner/ido-completing-read-plus https://github.com/DarwinAwardWinner/ido-completing-read-plu... [2]: https://github.com/DarwinAwardWinner/with-simulated-input https://github.com/DarwinAwardWinner/with-simulated-input
- the_af 7y ago
  You have a point and automated tests are definitely a big deal. However, as Wikipedia summarizes about "No Silver Bullet": > "While Brooks insists that there is no one silver bullet, he believes that a series of innovations attacking essential complexity could lead to significant improvements." So I'd say your experience doesn't contradict his point. Automated testing is not an orders of magnitude improvement, and software projects continue to fail or be flawed at an alarming rate, but it definitely helps! (like Brooks also said of high-level languages).