It's interesting that he considers testing to be a normal part of CI - "Once I'm done I carry out an automated build on my development machine. Only if it all builds and tests without errors is the overall build considered to be good." I have worked on projects of 30+ programmers where the dev process was called "continuous integration", but what that meant was "check in your code as often as possible, regardless of if it works". There were no automated tests to check your code beforehand, and most programmers didn't even bother to see if their code compiled before adding changes to source control.
I have also worked on projects where we had a "preflight" process. This meant that all potential changes were uploaded to a build machine and tested with the head branch to see if they compiled. Only if they successfully compiled were the changes actually added to source control. This sounds a lot like what they call 'pending head' - http://martinfowler.com/bliki/PendingHead.html . It's interesting that Fowler doesn't consider pending head/preflight a necessary part of CI or of good development; IME it dramatically cuts down on broken builds because it keeps developers honest. Didn't check to see if your code compiles? Too bad for you, it's not going in.
Fowler mentions several problems with CI builds still breaking. "One reason is discipline, people not doing an update and build before they commit". So maybe he would agree that preflight/pending head is beneficial. It also helps because you can go home on time - you don't have to stick around and babysit a build process if you commit code late in the day. That saves dev time and makes things progress faster.
Part of the point is not that the article tells you something you didn't know, but that it describes bad situations in a heartfelt and humorous manner. e.g. Objectively, sure, most people would say "IT workers need certain tools to do their job". But obviously some managers and organizations don't get that. The list is funny, because I've seen these things happen, and I can empathize with the fight people went through while learning some of them.
Seconded, thanks for writing this. I especially like point 5, because I hear people and corporations use the "if you've done nothing wrong" argument all the time.
This is exactly why easy-to-use programs that can ecrypt or anonymize your data are good. People are willing to use something like Skype because it's easy to set up and run. Want to call someone? Type in a phone number and hit 'call'. The average user doesn't know or care that their conversation is being encrypted, but they benefit nonetheless.
I'm really glad to see programs like Adium, used by the majority of my OSX friends, can encrypt conversations by default, and interfaces perfectly with options like OTR ( http://www.cypherpunks.ca/otr/ ). I've managed to convince exactly one friend to use OTR - it's not an effective way to fix things because most people don't care. Getting programs to have useful defaults that protect you while still being easy to use is the key.
Now all we need is an open-source version of Skype ( http://www.qutecom.org/ ? ) that joe-anybody can use on their phone :P
It seems like this guy is a big fan of the [Ben and Jerry's] (http://www.joelonsoftware.com/articles/fog0000000056.html) organic company model, and is deriding YC for being more of the "amazon" big burst type model (or at least accusing YC of creating small startup companies that follow the Amazon model). This analogy is slightly flawed, because, like ViaWeb, most of the startups that YC funds don't really seem like Amazon model companies. I would say that the author of this article is drawing the line between "organic startup" and "explosive funded company" much closer to the side of startups that start small, and including YC funded companies on the "explosive funded" side. That may account for some of his anger.
FWIW, his piece does have a good point: that a viable startup should be able to continue along a successful path even if they get rejected by YC. But as other people have noted there are benefits to being funded by YC: firstly they can [remove some of your distractions](http://news.ycombinator.com/comments?id=9439) and give you good advice; and secondly, applying to and being rejected by YC might just [force you to step up and improve your company](http://news.ycombinator.com/comments?id=9486). While there certainly are (and should be) companies that don't need YC to become successful, I think if you can get ahead by getting funded, then you should do it, and that's why YC really matters.
I think the most interesting thing about article is that people who fall into the "old news" camp probably didn't need the Cliffs Notes to understand what Paul meant. Once I understood what the original essay was about, I wasn't reminded of Microsoft's balance sheet, nor did I think they would be going out of business. The fact that they aren't non-existent but are no longer relevant just seems... intuitive.
I have also worked on projects where we had a "preflight" process. This meant that all potential changes were uploaded to a build machine and tested with the head branch to see if they compiled. Only if they successfully compiled were the changes actually added to source control. This sounds a lot like what they call 'pending head' - http://martinfowler.com/bliki/PendingHead.html . It's interesting that Fowler doesn't consider pending head/preflight a necessary part of CI or of good development; IME it dramatically cuts down on broken builds because it keeps developers honest. Didn't check to see if your code compiles? Too bad for you, it's not going in.
Fowler mentions several problems with CI builds still breaking. "One reason is discipline, people not doing an update and build before they commit". So maybe he would agree that preflight/pending head is beneficial. It also helps because you can go home on time - you don't have to stick around and babysit a build process if you commit code late in the day. That saves dev time and makes things progress faster.
Very good article; thanks for posting.