8 ms·

Do not be too much impressed by big names and buzzwords. The [very] successful process of developing the Linux kernel with nothing but git, mailing lists and a

Do not be too much impressed by big names and buzzwords. The [very] successful process of developing the Linux kernel with nothing but git, mailing lists and a small set of simple rules (no meetings, no Scrum, no BS) proved to be good-enough. It is not only Linux kernel, there are hundreds of other "decentralized, no-water-fall" projects, notably FreeBSD, OpenBSD, Xorg, LLVM, Golang, CPython, Ruby, you name it. It is much better to consider the differences between a commercial organization (a corporation) with all that bureaucracy obsessed with keeping its positions and budgets, etc. and a team of enthusiastic professionals with their own "inner" motivations and goals. Corporations are producing products to make profit, while teams of enthusiasts are producing (evolving) tools and services for themselves. The difference is the same as between McDonald's and family/home-made-for-themselves food.) Consider, for example, LLVM/Clang (backed by Apple) as high quality and no-cost alternative to VS. Its used as a primary compiler for OS X, iOS and FreeBSD and optional one for Android NDK. And, look ma, no bureaucrats, no meetings, no Scrum.

snambi 12y ago
agree 100%. waterfall and agile/scrum, both are BS.
scribu 12y ago
I'm not sure what you're suggesting: that corporations should just adopt the Linux kernel development approach? that all software should be developed as open source? Like you said, a corporation is not the same as a team of enthusiasts, so it seems sensible that what works for the former doesn't work for the later and vice-versa.
- dschiptsov 12y ago
  I am just trying to switch attention form popular memes to the facts that development of very complex and high-quality software could be done in a very different, no-BS, good-enough way.
bignaj 12y ago
LLVM/Clang and Visual Studio are not analogous... LLVM/Clang is a compliler/compiler frontend while Visual Studio is an IDE. You're looking for Visual Studio vs. Eclipse or .NET vs. Mono etc. in each case I think most see the no-cost alternative as quite obviously inferior. This weakens your argument a bit.
- dschiptsov 12y ago
  Do you realize how much more complex is the optimizing compiler part compared to the IDE part? My bet is that there are two separate sub-divisions working on them. OK, let's consider only compilers, if you wish..) Btw, GNU Emacs, which is another "miracle" of software engineering, is a good-enough IDE part for Clang. Together, in pair, they are, in my opinion, even more flexible and less resourse-wasting than VS. And (surprise!) cross-platform.
  - bignaj 12y ago
    It sounds like you have a very firm background in the Unix/Linux world but you have no idea what you're talking about when it comes to Windows-based development. For reference: I'm primarily a Unix/Linux developer but I work for Microsoft so I know what VS is about too. I understand what you're trying to say but it weakens your argument when you clearly haven't evaluated both sides. It sounds like you don't know how GNU Emacs was developed either -- the GNU version of Emacs was developed not by Scrum or Agile or "Waterfall" but by Richard Stallman's neckbeard in the MIT AI Lab...
    - dschiptsov 12y ago
      There was a link to Stallman's emacs paper back from 80s. Have you read it?) The "miracle" of Emacs in that it has a very powerful DSL which uses proper abstractions - buffers, paragraphs, blocks, strings, fonts, characters etc. embedded into a Lisp. Thus it is a thoroughly programmable (not just extensible) editor. It is quite beneficial to get familiar with ideas and design decisions behind Emacs, especially in the age of Java and copy-paste based coding.
  - 12y ago
panzerboy 12y ago
How do you know how the LLVM/Clang development is done inside Apple? Maybe they do use scrum, etc.
- deleted 12y ago
  [deleted]
walshemj 12y ago
And Agile doesn't suit 100% of development projects
iolothebard 12y ago
I work at a government agency, no scrum, no agile, no nothing. It's so bad I'd kill for waterfall. I personally love Visual Studio. Using continuous integration was an eye opener to me, I'm still not sold on continuous deployment though (on call isn't a good option IMO for a developer).
- dpark 12y ago
  Infrequent deployments don't prevent on-call scenarios. Stuff can and does still break between deployments, as external dependencies change, load increases or it's characteristics change, "time bomb" bugs go off, or any of a huge number of other things happen. Infrequent deployments mean that responding to these events is slower and more costly. Infrequent deployments also greatly increase the risk of problems during deployment, because infrequently exercised pieces of code (i.e. The deployment code/scripts) are more likely to be buggy, and because gobs of changes pile up between deployments. With that said, continuous deployment probably should not be happening at night or on the weekends unless you have rock-solid automatic rollback and the necessary monitoring to trigger it.
- snowwrestler 12y ago
  I think the idea is that continuous deployment is like working out a muscle. At first it is way more painful that the status quo. But over time the muscle (deployment team/system) can adapt to the workload and become stronger. But it only works if you have the time and resources to react to what happens. For example if you find out that differences between dev and prod servers can cause problems, you could add a tool like Chef/Puppet/Ansible to prevent those differences. But if you don't have the time or resources to invest in that sort of change (as in many government agencies), then continuous deployment will just pack more problems into a shorter period of time. This would be analogous to lifting weights, but never getting enough sleep or good nutrition. Under those circumstances, a person will just get weaker and more injured over time.
- thearn4 12y ago
  > I work at a government agency, no scrum, no agile, no nothing. It's so bad I'd kill for waterfall. Ditto, though we eventually adopted a modified form of scrum for the project that I'm on. Is the decision out of your control?

snambi 12y ago

agree 100%. waterfall and agile/scrum, both are BS.

scribu 12y ago

I'm not sure what you're suggesting: that corporations should just adopt the Linux kernel development approach? that all software should be developed as open source? Like you said, a corporation is not the same as a team of enthusiasts, so it seems sensible that what works for the former doesn't work for the later and vice-versa.

dschiptsov 12y ago
I am just trying to switch attention form popular memes to the facts that development of very complex and high-quality software could be done in a very different, no-BS, good-enough way.

bignaj 12y ago

LLVM/Clang and Visual Studio are not analogous... LLVM/Clang is a compliler/compiler frontend while Visual Studio is an IDE. You're looking for Visual Studio vs. Eclipse or .NET vs. Mono etc. in each case I think most see the no-cost alternative as quite obviously inferior. This weakens your argument a bit.

dschiptsov 12y ago
Do you realize how much more complex is the optimizing compiler part compared to the IDE part? My bet is that there are two separate sub-divisions working on them. OK, let's consider only compilers, if you wish..) Btw, GNU Emacs, which is another "miracle" of software engineering, is a good-enough IDE part for Clang. Together, in pair, they are, in my opinion, even more flexible and less resourse-wasting than VS. And (surprise!) cross-platform.
- bignaj 12y ago
  It sounds like you have a very firm background in the Unix/Linux world but you have no idea what you're talking about when it comes to Windows-based development. For reference: I'm primarily a Unix/Linux developer but I work for Microsoft so I know what VS is about too. I understand what you're trying to say but it weakens your argument when you clearly haven't evaluated both sides. It sounds like you don't know how GNU Emacs was developed either -- the GNU version of Emacs was developed not by Scrum or Agile or "Waterfall" but by Richard Stallman's neckbeard in the MIT AI Lab...
  - dschiptsov 12y ago
    There was a link to Stallman's emacs paper back from 80s. Have you read it?) The "miracle" of Emacs in that it has a very powerful DSL which uses proper abstractions - buffers, paragraphs, blocks, strings, fonts, characters etc. embedded into a Lisp. Thus it is a thoroughly programmable (not just extensible) editor. It is quite beneficial to get familiar with ideas and design decisions behind Emacs, especially in the age of Java and copy-paste based coding.
- 12y ago

panzerboy 12y ago

How do you know how the LLVM/Clang development is done inside Apple? Maybe they do use scrum, etc.

deleted 12y ago
[deleted]

walshemj 12y ago

And Agile doesn't suit 100% of development projects

iolothebard 12y ago

I work at a government agency, no scrum, no agile, no nothing. It's so bad I'd kill for waterfall. I personally love Visual Studio. Using continuous integration was an eye opener to me, I'm still not sold on continuous deployment though (on call isn't a good option IMO for a developer).

dpark 12y ago
Infrequent deployments don't prevent on-call scenarios. Stuff can and does still break between deployments, as external dependencies change, load increases or it's characteristics change, "time bomb" bugs go off, or any of a huge number of other things happen. Infrequent deployments mean that responding to these events is slower and more costly. Infrequent deployments also greatly increase the risk of problems during deployment, because infrequently exercised pieces of code (i.e. The deployment code/scripts) are more likely to be buggy, and because gobs of changes pile up between deployments. With that said, continuous deployment probably should not be happening at night or on the weekends unless you have rock-solid automatic rollback and the necessary monitoring to trigger it.
snowwrestler 12y ago
I think the idea is that continuous deployment is like working out a muscle. At first it is way more painful that the status quo. But over time the muscle (deployment team/system) can adapt to the workload and become stronger. But it only works if you have the time and resources to react to what happens. For example if you find out that differences between dev and prod servers can cause problems, you could add a tool like Chef/Puppet/Ansible to prevent those differences. But if you don't have the time or resources to invest in that sort of change (as in many government agencies), then continuous deployment will just pack more problems into a shorter period of time. This would be analogous to lifting weights, but never getting enough sleep or good nutrition. Under those circumstances, a person will just get weaker and more injured over time.
thearn4 12y ago
> I work at a government agency, no scrum, no agile, no nothing. It's so bad I'd kill for waterfall. Ditto, though we eventually adopted a modified form of scrum for the project that I'm on. Is the decision out of your control?