4 ms·

Not my experience at all. - We happily adopted a CI system from another team in 1998. - We had a decent unit testing framework and a fair bit of automation fo

Not my experience at all. - We happily adopted a CI system from another team in 1998. - We had a decent unit testing framework and a fair bit of automation for integration testing (although yes, some aspects of UI were hand tested periodically). - We continuously refactored and improved existing code, especially if we touched something in it or around it. The only practice I think was poor then was mixing the refactoring and new work into a single commit, which I would never do today. - I was using source control even in school in the late 80s, and I’ve never come across a team that didn’t, although I’m sure they did exist at that time. - As far as deployment, everything I’ve worked on has been shipped on a very episodic basis (anywhere from a month between shipping to a few years), so most of the automation I’ve seen there from early on was about deploying internally for testing, and that’s always been more or less automated. Although I did work at one place that tried Scrum for a little while around 2003-2005, the only practice I’ve generally seen adopted from that in the remaining years has been having periodic check-ins on status, e.g. monthly demo days to show off accomplishments from the last month. These are relatively low-prep although not impromptu, and that practice isn’t uniform. With all that said, some things I have seen change, which aren’t mentioned by parent: - Much more emphasis on developers writing tests. In the 90’s test teams were sometimes as large as development teams, and usually way behind the development team in progress. There was a belief that developers couldn’t possibly write good tests, or simply wouldn’t. - I never worked anywhere where it was “docs first”, at least not to the extent that people mean that when they talk about older development practices. We did sometimes write the equivalent of a 1-pager to get everyone aligned on what particular work was about, and had a meeting to discuss and determine if everyone was in fact aligned. I think that was very useful, and sadly what I see more often than not now is “code first” meaning that you write code and then try to use code reviews to deal with everything, which means that what could have been an hour of writing something up and an hour meeting turns into someone spending days coding something that has to be thrown away because it’s so clear during code reviews that the approach is the wrong one. So now this “agile” approach means a throwaway work sometimes because people aren’t communicating in any meaningful way before writing code. [edited formatting]

michael1999 3y ago
XP never claimed to invent any of those practices. But they were unevenly distributed. I note that 1998 was ~25 years ago, so I'm not sure we disagree here. You just described CI as a new-ish practice you adopted from another team. I'm happy you had your experience. But I will testify I've seen lots of places that would slap your hand if you touched code to "clean it up". When "testing" was two people running a week-long manual script, narrowing the scope of changes was a required practice! As for developer testing: a core idea of XP is that we developers should take responsibility for the quality of the code we ship. Test-first was a practice to support that goal. Automated testing wasn't completely unknown, but many shops had zero automated tests. Or if they had automated tests, they were clicky-clicky tests run by a ui-automation tool, and were written by the testing team. Developer written tests were rare back then. I remember interning at MS in the 90s and how proud they were that their target tester:developer ratio was >1! The creation of JUnit was an important historical event for us. As for the lack of communication and wasted work: I completely agree. Turning a story/use-case problem statement into a concrete design has to happen sometime. We used to do a whole-team tasking meeting for each story we opened, and group estimate of our tasks on the whiteboard. Combined with pairing, whole team rotation, and continuous integration, there was very little opportunity for someone to get lost.
- subharmonicon 3y ago
  I don’t doubt anything you’re saying, either. I was just providing another perspective. I think one thing I have seen over the years is people making extreme assumptions based on experiences they hear via the grapevine, and seeing more perspectives seems like one way to counter that. For example I have seen the claim here that CI systems were somehow new in the same timeframe that XP and Scrum were first written about and being adopted, and that testing was always an afterthought back then, etc. If anything I think we were often building more reliable and higher quality systems in that timeframe, if only because there was more alignment that testing and fixing bugs mattered. Today I get responses like “quality isn’t just about bugs” if I am critical about the quality of a particular product. As if what users want is 2N as many features, none of which quite work rather than N features that are all solid.

michael1999 3y ago

XP never claimed to invent any of those practices. But they were unevenly distributed. I note that 1998 was ~25 years ago, so I'm not sure we disagree here. You just described CI as a new-ish practice you adopted from another team. I'm happy you had your experience. But I will testify I've seen lots of places that would slap your hand if you touched code to "clean it up". When "testing" was two people running a week-long manual script, narrowing the scope of changes was a required practice! As for developer testing: a core idea of XP is that we developers should take responsibility for the quality of the code we ship. Test-first was a practice to support that goal. Automated testing wasn't completely unknown, but many shops had zero automated tests. Or if they had automated tests, they were clicky-clicky tests run by a ui-automation tool, and were written by the testing team. Developer written tests were rare back then. I remember interning at MS in the 90s and how proud they were that their target tester:developer ratio was >1! The creation of JUnit was an important historical event for us. As for the lack of communication and wasted work: I completely agree. Turning a story/use-case problem statement into a concrete design has to happen sometime. We used to do a whole-team tasking meeting for each story we opened, and group estimate of our tasks on the whiteboard. Combined with pairing, whole team rotation, and continuous integration, there was very little opportunity for someone to get lost.

subharmonicon 3y ago
I don’t doubt anything you’re saying, either. I was just providing another perspective. I think one thing I have seen over the years is people making extreme assumptions based on experiences they hear via the grapevine, and seeing more perspectives seems like one way to counter that. For example I have seen the claim here that CI systems were somehow new in the same timeframe that XP and Scrum were first written about and being adopted, and that testing was always an afterthought back then, etc. If anything I think we were often building more reliable and higher quality systems in that timeframe, if only because there was more alignment that testing and fixing bugs mattered. Today I get responses like “quality isn’t just about bugs” if I am critical about the quality of a particular product. As if what users want is 2N as many features, none of which quite work rather than N features that are all solid.