3 ms·
Completely agree. SCCS goes back to 1973. I meant my comment about the lack of source control as a remark on how many shops had no hygiene at all, not that XP
by michael1999 3y ago
Completely agree. SCCS goes back to 1973. I meant my comment about the lack of source control as a remark on how many shops had no hygiene at all, not that XP was the inventor of it. Joel wasn't a fan of the agile hype, and published his test in opposition to it. I agree with his assertion that much of the value was in dev hygiene: builds, tests, automation, and continuous delivery. And those could be adopted separately from the rest of "Agile". But agile had the buzz. Was the buzz part cause of broader adoption? I believe yes. Agile consultancies inflicted build hygiene on reluctant teams in the same way that Rational Rose salespeople inflicted RUP on them. And I'd argue those early Agile consulting engagements were better value-for-money than those RUP licenses.
I feel more strongly that continuous integration and continuous testing became widespread as part of the early agile movement. Again - none of those practices were invented there. Booch published his "Booch Method" in 1991, and Microsoft had monster overnight automated testing when I was there in 1992. But Beck wrote SUnit in 1995, and then JUnit when the Smalltalk diaspora fled to Java. XP was about evangelizing practices the authors had found to work and turning them to 11. CruiseControl came out of Thoughtworks in 2001, and the XP book literally coined the term "continuous integration".
- PH95VuimJjqBqy 3y ago> Something people forget about the rise of agile is how many of the practices have become mainstream I don't know how else to interpret this other than the list given are practices of agile, I responded because they definitely were not. You may be right about the consultants bringing in better practices overall, but that goes back to my point that agilistas love to take credit for things that are not agile. I would also argue that cloud was more the motivator for good CI/CD than agile. At the end of the day it's all mixed together, but when you try to attribute something that's just good software dev to agile when it has nothing to do with agile itself you open yourself to the criticisms I've leveled.
- michael1999 3y agoIf your complaint is that smart people were already doing those things, but that better way had no name, or industry leadership, just word-of-mouth and vibes -- I agree? That's kinda why the whole manifesto came about. It was people collecting a bunch of successful practices and branding it so they could more effectively evangelize them. That's what manifestos are. But like all revolutions, sometimes you win and need to declare victory and go home. Delivery agility won. The remaining "Agile Industry" is mostly cancer. To be clear - I'm asserting that the Joel test was part of the broader delivery agility current in the industry. This current sprang from the lessons of the first web boom, and the fantastic changes in delivery possible on the web. In the shrink-wrap floppy world, yearly releases left so much time to just wander around and get lost. Head would spend weeks not compiling, and savvy devs knew the right times to merge head into their long-lived feature branches. Joel was explicitly reacting against that, and to SEMA, RUP, and the 90s planning driven movement where sub-module teams would write against fixed apis that hadn't been implemented yet. Maybe I'm exaggerating. I agree that he differed sharply from the XP and other agile folks in some ways, and would never have signed the manifesto. But who was Joel talking to when he wrote: "Another great thing about keeping the bug count at zero is that you can respond much faster to competition. Some programmers think of this as keeping the product ready to ship at all times. Then if your competitor introduces a killer new feature that is stealing your customers, you can implement just that feature and ship on the spot, without having to fix a large number of accumulated bugs." Or Joel again: "The other crucial thing about having a schedule is that it forces you to decide what features you are going to do, and then it forces you to pick the least important features and cut them rather than slipping into featuritis (a.k.a. scope creep)." You can argue that people were already doing these things, but clearly Joel thought there was an audience that wasn't (including early 90s Microsoft!). Compare that to the manifesto: "Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage." Anyway: Single-backlog. Ship at any time with a single click. High quality. Clear comms. Dev focus. Blah blah. It's not Scrum, but I'd definitely call that agile as we understood it in 2001. If you think that's just good practice, and has nothing to do with "agile", I'm happy to retire the word. Time to move on.
- PH95VuimJjqBqy 3y agowhat you're doing is akin to claiming LEAN manufacturing should be credited with the advent of anti-lock brakes because LEAN manufacturing was being employed during the time when anti-lock brakes became popular. or guns should be credited with the advent of plumbing because guns were popular when plumbing became a thing. The entire reason I pointed out that the joel test existed was to point out that industry leaders were actively trying to get people to become more sophisticated completely outside of agile. Why aren't you claiming agile is the reason people started creating timelines for software releases? Oh what's that, agile is really into NOT having those but releasing when it's ready? It's almost as if different market forces were at play. At some point you have to put your own biases to the side and realize that you do your own agenda more harm than good here.
- michael1999 3y agoThanks for the clear thinking. I appreciate the time. Cheers.
- PH95VuimJjqBqy 3y agosometimes you just need guidance, glad to see your humility allows for it.