8 ms·

20.5 Years of XP and Agile (2020)

56 points by ingve 3y ago

jamghee 3y ago
I working in XP for a bit and the constant pair programming aspect was simply too fatiguing for me. I enjoy pairing every now and then on certain problems, but the constant presence of another person left me utterly drained at the end of every day.
- pjmlp 3y ago
  Same here, just the idea of forced XP is enough for me to start considering other positions.
- kstenerud 3y ago
  Yup, my major beef with XP back in the day was in its arrogance: This is the way to do things, and if you don't do it entirely this way, you're not extreme programming! (that was literally in the manifesto) But the article highlights the good points of agile, and I agree with them: - Iterative development (smaller steps with faster feedback) - Unit tests (and building with unit tests in mind) - Code Refactoring (which you can do confidently when you have unit tests) The rest of XP/Agile is not necessary, and in some cases even detrimental. YMMV
  - azangru 3y ago
    > if you don't do it entirely this way, you're not extreme programming But isn't this... OK? Extreme programming is probably defined as a certain set of practices, and if you are doing a subset of that, you are doing something else. This doesn't make you into a bad or a lazy person; it just means that your process is something other than extreme programming. It's the same with scrum. It is extremely common for people to pick some practices from the scrum framework, skip others, and still claim that they are doing scrum. It gets very confusing when people do this.
    - pydry 3y ago
      Scrum practitioners/coaches always seemed to have this idea that if Scrum wasnt working then you werent doing it properly. Scrum had some serious problems, too, but nobody wanted to admit to them.
      - brightball 3y ago
        Scrums biggest problem has always been management interpretation of sprints as deadlines (commitments) and not estimates (forecasts). The former eventually leads teams to lowball everything to make sure they always complete everything at the expense of trying to accomplish more. Which will then lead the company to wonder why everything is so slow. Getting people at the top to understand that challenge is the hard part.
        bboygravity 3y ago
        Scrum, XP and/or Agile are not going to save you if the guy leading the project decides the hardware and firmware have to be completely re-done for no good reason other than his own opinion, lack of experience and ego mixed in with a bit of "not invented here syndrome", "if it ain't broken fix it anyway" and "make it complex not simple stupid" (recent random example). My point being: other aspects of companies and teams are far more important than the latest fashionable project management methodologies/frameworks/philosophies. I find it hard to care about these trends.
        brightball 3y ago
        The critical piece to any framework is how work is prioritized. If it’s by 1 guy, you will have the problems you describe. If you have an approach that forces the people doing prioritizing to weigh Return on Investment (benefit or value / estimated time) to largely guide the priorities, busywork with little benefit like you describe won’t be prioritized. It’s critical.
        bluGill 3y ago
        Often the people at the top understand. However what most developers fail to understand is the guy at the top really needs accurate estimates. the more accurate the estimate the better he can do their job. Thus they are constantly loohing for a magic bullet that gives them that. it doesm't need to be perfect, but the closer the better.
  - michaelcampbell 3y ago
    > This is the way to do things, and if you don't do it entirely this way, you're not extreme programming! Which is fine. They defined a set of practices, called it XP, and if you don't do these, you're not doing XP.
  - somewhereoutth 3y ago
    Code refactoring with unit tests is fine when it is within the unit test units, but when it crosses unit boundaries the tests often must be re-written, doubling the effort required.
- scrapheap 3y ago
  I know some people really work well when pair programming, but I find that I either slip into Student Mode or Teacher Mode when I try it. Either the other person knows the environment we're working in (architecture, codebase, etc) a lot better than I do, and I'm using the session to gather as much information as I can, or I know the environment better and so I'm explaining why I'm doing things. If the other person and I are on par with the environment then we're more likely to have a discussion about what we're wanting to achieve and how best to go about it, but then one of us will go away and knock out a first cut for the other person to review. I do wonder what differs between groups of people who can actually do pair programming and those that (like me) that can't.
  - JackMorgan 3y ago
    I think slipping into student mode or teacher mode is a fantastic reason to pair: it's full time training. You quickly will all rise to the skill level of the best parts of every engineer on the team. Otherwise training is rare and slow.
  - pydry 3y ago
    My mode is either driving and listening to advice or watching and trying to spot things the driver missed. Occasionally I do side-work if Im not driving - e.g. look something up, message devops, a very small PR etc. so the driver can maintain focus. I find it to be much more effective that working alone simply because so much stuff that would take me 20 minutes to to go down a rabbit hole ends up being caught by an extra pair of eyes in 4 seconds.
  - j4yav 3y ago
    I always thought that student / teacher mode was the very best form of pair programming.
- willsmith72 3y ago
  I actually loved it. I had never learned so much or shipped so quickly and reliably. And then I moved teams... And realised it's all about the people and culture around you. I probably wouldn't sign up for it again when joining a new company, because at its worst it's absolute torture, but I still believe that at its best there's nothing like it.
  - michaelcampbell 3y ago
    You both can be right. It can be the best way for you, and it can also be utterly exhausting for them. Personally, I'm not willing to get rid of _all_ my comfort zone to get something out the door more efficiently, where shareholders and C-levels get rich off my labor, and if I'm very lucky, I get to keep doing that.
    - willsmith72 3y ago
      Well if I saw my work life like that, why improve any system or take any initiative on anything? I like working in teams with ownership over their outcomes, and reward for their success
      - michaelcampbell 3y ago
        Sure, but I can only enjoy so many free pizzas.
- djtango 3y ago
  first, there's a definitely a stamina to it - I worked in an XP team for best part of 3 years and have at other jobs done a lot of full-time pairing (sometimes months at a time). Second, there's a chemistry element. When there's good chemistry it can be quite effortless and the chemistry can grow - as you start to develop an intuition for how the other person thinks there's less communication and mental jostling. I've had remote pairing sessions that have felt almost as fun as online gaming.
- gramie 3y ago
  I went through a period of a couple of months where I pair-programmed almost every day, and it was probably the most productive time of my career. My partner was very junior, and new to the project, and the process of explaining things to him definitely helped avoid some of my blind spots. He had several good insights and ideas, too, coming in with fresh eyes. It was high-energy, though, and an extended period might well have been fatiguing.
- crabbone 3y ago
  If I had to pair-program, I'd probably call in sick. And if this was a repeated demand, I'd eventually just quit. To me, this is one of the worst ways to work. I very much prefer to communicate in writing, and at prearranged times. To me, the idea that there's another person working with me on the same problem at the same time is as absurd as having another person cooking in the same kitchen with me, or painting on the same canvas as me. Whatever result I can produce on my own, it will be ten times worse if I had to do it with someone else working on the same problem with me.
mindvirus 3y ago
It's so interesting to hear ideas that feel so timeless today - "unit testing", "refactoring" - were of course not.
noelwelsh 3y ago
XP is the only methodology I've used that gave direction on what programmers should be doing. Most methodologies have plenty to say on what happens around the programming, such as planning and design, but when it comes to producing code---the entire point of the exercise---they treat it as a black box. I don't think XP is the final word on programming, or necessarily even good in all its suggestions, but I think it's worth knowing just because it tries to tackle the most important part of software development.
deleted 3y ago
[deleted]
zogomoox 3y ago
And after 20 years Agile has been subverted by faux-agile methods such as Scaled Agile Framework that unfortunately have a lot of traction in the industry.
FrustratedMonky 3y ago
The original Agile Manifesto was very valuable, and really did strike a cord. The original Manifesto was actually about being "Agile", developers being developers. How to really focus on being the best developer. Moving fast, focused, cutting away un-needed tasks. I'm continually disappointed that it spawned some giant consulting industry that became an onerous layer on development, a wet blanket.
begueradj 3y ago
The main philosophy of XP, as stated by Kent Beck himself, is to take everything good to its extreme (hence the appellation Extreme Programming). For example, if testing is good, then it must be done to the extreme. Basically this means you will need to have a 100% test coverage to comply to XP. But history proves that extremism and fanaticism are bad and harmful in every area of life, including in software development. You can, for example, read about the consequences of testing to the extreme here [1] [1]: https://brandur.org/fragments/100-percent-coverage https://brandur.org/fragments/100-percent-coverage
- wesselbindt 3y ago
  Where did the extreme programming gurus advocate for 100% coverage? I've never read the original texts, but I'm familiar with some of their writing, and this doesn't quite jive with my conception of their opinions. Do you have a specific place I can look?
  - ryan-duve 3y ago
    Parent commenter said "basically" have 100% test coverage, and I'm not sure what is meant by that. From the text[0]: > Any program feature without an automated test simply doesn't exist. Programmers write unit tests so that their confidence in the operation of the program can be part of the program itself. Customers write functional tests so that their confidence in the operation of the program can become part of the program, too. The result is a program that becomes more and more confident over time -- it becomes more capable of accepting change, not less. > You don't have to write a test for every single method you write, only production methods that could possibly break. Sometimes you just want to find out if something is possible. You go explore for half an hour. Yes, it is possible. Now you throw away your code and start over with tests. [Emphasis mine.] I can see how this is interpreted both ways, so I'll leave it to you. For what it's worth, I found the book to be an easier read than most books on coding practices. [0] Extreme Programming Explained by Kent Beck, Chapter 10 under "Testing"
  - michael1999 3y ago
    XP prescribes test-first. Some people have interpreted that as being about 100% coverage, but that misses the point.
SillyUsername 3y ago
Agile had it's moment back then. Is agile still appropriate today? Now we have agile coaches (per team), agile leads (all teams' agile lead), scrum masters (the guy who does the meetings), and project owners (giving requirements), and lead project owners (planning) all trying to get developer time and attention. Right size this, OKR that, attend this attend that. Wasn't agile always about finding what works best for the team and doing it, with consideration of tracking what works well and what doesn't, and refining the process to fix it? Now it seems to be some sort of glorified job role, so even if the team get it right and run well they're patronised into attending non stop meetings from non technical staff trying to justify their jobs and whose own job role even states if the team is running well and self organising, then they need no involvement. All I hear these days is, how can we fix that? And the team answers; the delay is off team, in either third parties, business itself, or we've worked around the bits that we can. The dev team is now being asked to fix other teams' delay causing problems and then effectively silently shamed for not doing it week after week (because it gets raised again and again). This is end game and wasting time if you're team reaches this point, yet the coaches still pound that shaming in like there's something that can be done in team. Of course these meetings aren't meant to do that, but when has human psychology ever been considered (being asked how to fix something a dev has no control over is now a common theme in questions I'm asked)? IMHO agile in its current bastardised form should be taken out the back and shot. When it became a rigid set of rules (oh but "that's not how it's meant to be applied" is the war cry!) which promotes long term job roles preaching it, adds nothing to the teams' ability to adapt, and the team is already meeting most sprint goals and deliverables, the team has hit peak agility already.
- TheBigSalad 3y ago
  Why do people always say agile doesn't work and then tell some personal baggage story that clearly shows their company is doing it wrong. Is agile really to blame?
  - ianis-h 3y ago
    Implementing true agile and keeping it clean of hiearchical management is so hard that it might not be the right choice for most companies... If something is to hard to implement, maybe it is the problem.
userbinator 3y ago
For a moment I thought this was about Windows XP, given the title and date... IMHO following any sort of methodology dogmatically is unlikely to give great results, and the best path is probably somewhere in between two extremes. Waterfall emphasises "plan ahead" --- a concept that seems to have completely disappeared from some types of software these days.
braza 3y ago
I was in the RUP universe for a period of my career and I would never want to go back on it agile was a refreshing breeze back then. However, the framework needs updates in several important areas: operations, data science, end of the PO figure and incorporating other actors as part of the feedback cycle, tech debt management, how to deal with uncertainty more efficiently, and so on. Unfortunately due to a lot of issues in our industry, agile got a lot of bad rep plus a lot of luggage it turns very hard to have a dispassionate discussion that the IQ of the participants does not drop 20%, at least. It's a shame, but I really would like to see some updates on this.
- eschneider 3y ago
  Fun fact: I worked at Rational for many years. We didn't even use RUP there.
jmclnx 3y ago
When I started out (80s), we would work closely with the real users and they got what the wanted. Back then development was text screens. Around 10 years later, some methodology came along and working with the users ended. This methodology was suppose to give the programmers more time to work. We ended up with frustrated users who started moving to Lotus 123 or Excel. Back then I developed (on the side) many processes where my users could get the data from the mainframe for use on their PCs. Agile came along later with prepackaged software, AMAPs(?), SAP, Oracle and many others that I have forgotten. Now we have many many users spending at least 50% of their time (some much more) testing upgrades instead of analyzing their data. End result, users are just doing what they can to get by whatever GUI screen is presented to them, not caring at all what data they are entering in. And most real work occurs in excel to the point where users are downloading gigs of data to their PC to get away from the canned, hard to use Enterprise Systems.
DrNosferatu 3y ago
Try building any high-stakes engineering project (say, a bridge, or a production operating system) like that… With Agile, at best, you will build an amateur treehouse. Sure, prototypes that test the viability of certain parts and aspects of the system are very useful. But having those prototypes and toy models then be “free-styled” (without a clear design document to be referenced - what exactly is the system supposed to do?) into a repurposed role to deliver the whole system’s functionality and reliability is the recipe to disaster. Or in other words: technical debt. - Where’s the Systems / Systems Integration perspective? - Where’s *Repeatability*? (middle management does like Agile to justify their many times useless positions) PS: I believe “Agile” explains a lot of the 737 MAX owes…
- DrNosferatu 3y ago
  The problem is that, in the software world, it’s very easy to disguise an amateur-quality treehouse as a high-stakes engineering project.
alberth 3y ago
Best Dev Methodology? What do people consider as the current best dev methodology?
taylodl 3y ago
I started my career back in the mid-80's and so I've lived with the process being described here. Kent Beck was a breath of fresh air and we all thought yes, this is what we've actually been doing! Mostly. Here's the thing: in some ways I think what we were doing back then was better. I just noted XP was essentially what we were doing anyway. Different teams and projects essentially chose their own internal methodology depending on what worked best for the project. Waterfall was what was presented to the project stakeholders. What does that mean? Paradoxically, we actually had more flexibility back then! Thanks to the tooling, which more or less standardizes the methodology, and all the Agile Coaches which have been trained on that tooling and standardized methodology - Agile today isn't very, well, agile - at least not from a development perspective. People point out that Agile allows for the requirements to change. No it doesn't. That's not a magic wand. Requirement changes still have project delivery impacts. Agile doesn't make that go away. It just provides for smaller iterations which facilitate the management of requirement changes. Know what? Iterative Waterfall, which we had been doing since the 80's (actual Waterfall is an artifact from the 70') also allowed for that. Now I live in a world of WaterScrumFall, which is absolutely the worst of all worlds.
michael1999 3y ago
Something people forget about the rise of agile is how many of the practices have become mainstream. Most shops I encountered 25 years ago: - had a manual build - deployed by hand - did all testing by hand - never touched code except for new features - might not even use source control But in the modern environment, we assume: - comprehensive source control, or even total BOM control - automated builds - automated tests - continuous integration - continuous refactoring - incremental design Congratulations, you are already doing half of XP! Those were all considered radical back in the day. What's left as purely "Agile" is the branded process stuff. E.g standardized meetings and titles like Scrum Master, SAF, etc. Given how prescriptive the business culture around it has become, it is a kind of anti-agile. So death to Agile, long live agile. Personally, I'm still an XP fiend at heart. Give me: a single list of prioritized work; a test suite I can trust that runs in < 15 minutes; and a dedicated team with good comms; and we'll tackle any problem you give us.
- bluGill 3y ago
  Most of those were considered normal best practice in watarfall shops I worked at. They were common, but we knew many not doing them and laughed at those fools.
- subharmonicon 3y ago
  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]
kitsune_ 3y ago
The main problem with the Agile industry is that the certificate mills give people the idea that they have to know nothing about software to work on/in software. Also Scrum as outlined by people like Jim Coplien would probably be kind of fine for certain set ups, but only a few agile coaches, POs or SMs know Scrum that well, instead it's a weird mix of apocryphal, illogical practices and superficial knowledge that, coupled with an inexperienced dev team, is similar to a giant Molotow cocktail that will sooner or later explode.
- Pet_Ant 3y ago
  Scrum is basically a set of necessary but not sufficient processes. I was sceptical about it, took the course, and aced the test. Scrum itself is like the rules for holding a good meeting. It's good common sense advice that I don't think you can actually reasonably object to. If it's not in the Scrum guide, it's not Scrum, truly find something objectionable in that: https://scrumguides.org/scrum-guide.html https://scrumguides.org/scrum-guide.html But in achieving that flawesseness, they made it so broad and vague that you really need to add additional practices to it. And then you got to be careful, mature, and thoughtful or else it's gonna turn into a shitshow... but if you just do Scrum you'll end up as a shitshow anyway. PS- to me personally the biggest flaw is that so much hinges on the definition of done being correct, and that is at least half the battle in dev and can almost single handedly save or sink an organisation in itself.
elzbardico 3y ago
Agile failed because it had a naive view point of politics. It never understood that the bureaucrat is the enemy and that the bureaucracy wouldn't give it up so easily. Instead, the bureaucracy did what does when it is threatened, it pretended to pay lip service to the agile principles while subverting them in order to survive and thrive.
- stcredzero 3y ago
  Agile failed because it had a naive view point of politics. It never understood that the bureaucrat is the enemy and that the bureaucracy wouldn't give it up so easily. Bureaucracy is just the human political animal expressing its awful nature in organizational systems. Instead, the bureaucracy did what does when it is threatened, it pretended to pay lip service to the agile principles while subverting them in order to survive and thrive. Amazing how Orwell never ceases to be relevant.
crabbone 3y ago
I want to reflect specifically on the testing part. Henrik Warne talks about how unit tests were an improvement to the development process, and how designing for testing was an improvement for program design. I think both are very naive ideas (as I think overall about Agile and XP). But, before I get to the "why" part, I want to first describe my perspective on how testing changed over time. The perspective on testing before the "shift left" happened was that testing is supposed to be adversarial. I.e. it was important that the testers don't know how the code works or what decisions did the development team make to solve higher-level problems the software was meant to solve. This was important so that testers wouldn't turn the blind eye to the software problems they would've otherwise gotten used to, or would have accepted the trade-offs before even getting into testing. The reason is very similar to how in clinical trials the participants aren't told whether they get placebo or the real drug. This is also why the testing would normally start after the software was in a shape ready for testing (i.e. after a reasonably long development interval). This is also why a lot of it was manual: there wouldn't have been time to develop utilities for testing since the testers didn't know what the software was like. But, of course, there were also commercial incentives to finish earlier. This is how "patch version" became a thing for example: a typical testing cycle would be to receive the system from the developers, to deploy it, to validate it (i.e. to ensure that the minimal required functionality is there), and then to try to "break" it. If the system broke, the developer would be notified. They then would have to fix the problems and deliver the fixes as patches. These patches then would be given a version number, and the testers would be required to use them to patch the deployed system in place, in order to continue testing. A system shipped to the customer would usually contain a bunch of patches, and the installation process would include patching as well. The downside of this system is the time it takes to get to the working product. The upside is the better overall quality of the product. The better quality comes from the testers working from specification rather than from their familiarity with the code. ---- So, unit tests. From the perspective of someone who had to manage CI for rather large organizations: unit tests give the least value for the most effort (among different test types). Because unit tests deal with the minutia of the code details they tend to change a lot, they grow stale very quickly, and they require a lot of maintenance because they tend to also multiply very quickly. Besides, most of the unit tests in every CI run test the code that didn't change anyways. They just burn electricity for no effect. It's very hard to come up with the system that would only apply unit tests where the code changed. In the end of the day, given the limited time and resources, if there's any test a developer should be spending their efforts on it's the end-to-end test. They don't change as often, and they at least can guarantee that the program, as a whole, works sometimes (unit tests have no useful guarantees about the whole program). ---- When it comes to designing for testing... it's also complicated. There are many dangers in doing this. Testing code is often a security backdoor. Testing code can also cause performance problems. There's a very delicate balance between the ways of how the system can be instrumented for testing and how much this instrumentation actually contributes to the quality of the system. My approach here is that as much as possible, the testing needs to be external to the system. This is to prevent tests from affecting the system, and especially from leaving undesirable artifacts in it. ---- Agile, or any other simplistic software development management process is just that: simplistic. It doesn't mean it "doesn't work" -- it means that it works sometimes. But, I wish we spent time on studying the process and discovering better way of doing things instead of trying to shoehorn things we meet in practice into existing simplistic process descriptions to justify their existence.
brailsafe 3y ago
I don't think I've ever been in a company that's used any Agile practice in an iterative fashion, or that's in any way thoughtful about structuring dev work. Managers adopt it as an arbitrary template for more compressed work, regardless of how well it fits into 2 weeks or 1-day standup cycles, then usually the same template permeates every other team, making it impossible to design a schedule that's appropriate out-of-sync with any other department or team. So I reduce the scope of my work to what can fit into 2 weeks and that I could have something tangible to speak about every single day, and there's no real feedback cycle engaged without a ton of friction and a raised eyebrow. I have a hard time believing that anything has ever shipped because the team chose Agile; any success determined only by deadlines, budget, and periodic (real) feedback cycles.

56 points by ingve 3y ago

I working in XP for a bit and the constant pair programming aspect was simply too fatiguing for me. I enjoy pairing every now and then on certain problems, but the constant presence of another person left me utterly drained at the end of every day.

pjmlp 3y ago
Same here, just the idea of forced XP is enough for me to start considering other positions.
kstenerud 3y ago
Yup, my major beef with XP back in the day was in its arrogance: This is the way to do things, and if you don't do it entirely this way, you're not extreme programming! (that was literally in the manifesto) But the article highlights the good points of agile, and I agree with them: - Iterative development (smaller steps with faster feedback) - Unit tests (and building with unit tests in mind) - Code Refactoring (which you can do confidently when you have unit tests) The rest of XP/Agile is not necessary, and in some cases even detrimental. YMMV
- azangru 3y ago
  > if you don't do it entirely this way, you're not extreme programming But isn't this... OK? Extreme programming is probably defined as a certain set of practices, and if you are doing a subset of that, you are doing something else. This doesn't make you into a bad or a lazy person; it just means that your process is something other than extreme programming. It's the same with scrum. It is extremely common for people to pick some practices from the scrum framework, skip others, and still claim that they are doing scrum. It gets very confusing when people do this.
  - pydry 3y ago
    Scrum practitioners/coaches always seemed to have this idea that if Scrum wasnt working then you werent doing it properly. Scrum had some serious problems, too, but nobody wanted to admit to them.
    - brightball 3y ago
      Scrums biggest problem has always been management interpretation of sprints as deadlines (commitments) and not estimates (forecasts). The former eventually leads teams to lowball everything to make sure they always complete everything at the expense of trying to accomplish more. Which will then lead the company to wonder why everything is so slow. Getting people at the top to understand that challenge is the hard part.
      - bboygravity 3y ago
        Scrum, XP and/or Agile are not going to save you if the guy leading the project decides the hardware and firmware have to be completely re-done for no good reason other than his own opinion, lack of experience and ego mixed in with a bit of "not invented here syndrome", "if it ain't broken fix it anyway" and "make it complex not simple stupid" (recent random example). My point being: other aspects of companies and teams are far more important than the latest fashionable project management methodologies/frameworks/philosophies. I find it hard to care about these trends.
        brightball 3y ago
        The critical piece to any framework is how work is prioritized. If it’s by 1 guy, you will have the problems you describe. If you have an approach that forces the people doing prioritizing to weigh Return on Investment (benefit or value / estimated time) to largely guide the priorities, busywork with little benefit like you describe won’t be prioritized. It’s critical.
      - bluGill 3y ago
        Often the people at the top understand. However what most developers fail to understand is the guy at the top really needs accurate estimates. the more accurate the estimate the better he can do their job. Thus they are constantly loohing for a magic bullet that gives them that. it doesm't need to be perfect, but the closer the better.
- michaelcampbell 3y ago
  > This is the way to do things, and if you don't do it entirely this way, you're not extreme programming! Which is fine. They defined a set of practices, called it XP, and if you don't do these, you're not doing XP.
- somewhereoutth 3y ago
  Code refactoring with unit tests is fine when it is within the unit test units, but when it crosses unit boundaries the tests often must be re-written, doubling the effort required.
scrapheap 3y ago
I know some people really work well when pair programming, but I find that I either slip into Student Mode or Teacher Mode when I try it. Either the other person knows the environment we're working in (architecture, codebase, etc) a lot better than I do, and I'm using the session to gather as much information as I can, or I know the environment better and so I'm explaining why I'm doing things. If the other person and I are on par with the environment then we're more likely to have a discussion about what we're wanting to achieve and how best to go about it, but then one of us will go away and knock out a first cut for the other person to review. I do wonder what differs between groups of people who can actually do pair programming and those that (like me) that can't.
- JackMorgan 3y ago
  I think slipping into student mode or teacher mode is a fantastic reason to pair: it's full time training. You quickly will all rise to the skill level of the best parts of every engineer on the team. Otherwise training is rare and slow.
- pydry 3y ago
  My mode is either driving and listening to advice or watching and trying to spot things the driver missed. Occasionally I do side-work if Im not driving - e.g. look something up, message devops, a very small PR etc. so the driver can maintain focus. I find it to be much more effective that working alone simply because so much stuff that would take me 20 minutes to to go down a rabbit hole ends up being caught by an extra pair of eyes in 4 seconds.
- j4yav 3y ago
  I always thought that student / teacher mode was the very best form of pair programming.
willsmith72 3y ago
I actually loved it. I had never learned so much or shipped so quickly and reliably. And then I moved teams... And realised it's all about the people and culture around you. I probably wouldn't sign up for it again when joining a new company, because at its worst it's absolute torture, but I still believe that at its best there's nothing like it.
- michaelcampbell 3y ago
  You both can be right. It can be the best way for you, and it can also be utterly exhausting for them. Personally, I'm not willing to get rid of _all_ my comfort zone to get something out the door more efficiently, where shareholders and C-levels get rich off my labor, and if I'm very lucky, I get to keep doing that.
  - willsmith72 3y ago
    Well if I saw my work life like that, why improve any system or take any initiative on anything? I like working in teams with ownership over their outcomes, and reward for their success
    - michaelcampbell 3y ago
      Sure, but I can only enjoy so many free pizzas.
djtango 3y ago
first, there's a definitely a stamina to it - I worked in an XP team for best part of 3 years and have at other jobs done a lot of full-time pairing (sometimes months at a time). Second, there's a chemistry element. When there's good chemistry it can be quite effortless and the chemistry can grow - as you start to develop an intuition for how the other person thinks there's less communication and mental jostling. I've had remote pairing sessions that have felt almost as fun as online gaming.
gramie 3y ago
I went through a period of a couple of months where I pair-programmed almost every day, and it was probably the most productive time of my career. My partner was very junior, and new to the project, and the process of explaining things to him definitely helped avoid some of my blind spots. He had several good insights and ideas, too, coming in with fresh eyes. It was high-energy, though, and an extended period might well have been fatiguing.
crabbone 3y ago
If I had to pair-program, I'd probably call in sick. And if this was a repeated demand, I'd eventually just quit. To me, this is one of the worst ways to work. I very much prefer to communicate in writing, and at prearranged times. To me, the idea that there's another person working with me on the same problem at the same time is as absurd as having another person cooking in the same kitchen with me, or painting on the same canvas as me. Whatever result I can produce on my own, it will be ten times worse if I had to do it with someone else working on the same problem with me.

mindvirus 3y ago

It's so interesting to hear ideas that feel so timeless today - "unit testing", "refactoring" - were of course not.

noelwelsh 3y ago

XP is the only methodology I've used that gave direction on what programmers should be doing. Most methodologies have plenty to say on what happens around the programming, such as planning and design, but when it comes to producing code---the entire point of the exercise---they treat it as a black box. I don't think XP is the final word on programming, or necessarily even good in all its suggestions, but I think it's worth knowing just because it tries to tackle the most important part of software development.

deleted 3y ago

[deleted]

zogomoox 3y ago

And after 20 years Agile has been subverted by faux-agile methods such as Scaled Agile Framework that unfortunately have a lot of traction in the industry.

FrustratedMonky 3y ago

The original Agile Manifesto was very valuable, and really did strike a cord. The original Manifesto was actually about being "Agile", developers being developers. How to really focus on being the best developer. Moving fast, focused, cutting away un-needed tasks. I'm continually disappointed that it spawned some giant consulting industry that became an onerous layer on development, a wet blanket.

begueradj 3y ago

The main philosophy of XP, as stated by Kent Beck himself, is to take everything good to its extreme (hence the appellation Extreme Programming). For example, if testing is good, then it must be done to the extreme. Basically this means you will need to have a 100% test coverage to comply to XP. But history proves that extremism and fanaticism are bad and harmful in every area of life, including in software development. You can, for example, read about the consequences of testing to the extreme here [1] [1]: https://brandur.org/fragments/100-percent-coverage https://brandur.org/fragments/100-percent-coverage

wesselbindt 3y ago
Where did the extreme programming gurus advocate for 100% coverage? I've never read the original texts, but I'm familiar with some of their writing, and this doesn't quite jive with my conception of their opinions. Do you have a specific place I can look?
- ryan-duve 3y ago
  Parent commenter said "basically" have 100% test coverage, and I'm not sure what is meant by that. From the text[0]: > Any program feature without an automated test simply doesn't exist. Programmers write unit tests so that their confidence in the operation of the program can be part of the program itself. Customers write functional tests so that their confidence in the operation of the program can become part of the program, too. The result is a program that becomes more and more confident over time -- it becomes more capable of accepting change, not less. > You don't have to write a test for every single method you write, only production methods that could possibly break. Sometimes you just want to find out if something is possible. You go explore for half an hour. Yes, it is possible. Now you throw away your code and start over with tests. [Emphasis mine.] I can see how this is interpreted both ways, so I'll leave it to you. For what it's worth, I found the book to be an easier read than most books on coding practices. [0] Extreme Programming Explained by Kent Beck, Chapter 10 under "Testing"
- michael1999 3y ago
  XP prescribes test-first. Some people have interpreted that as being about 100% coverage, but that misses the point.

SillyUsername 3y ago

Agile had it's moment back then. Is agile still appropriate today? Now we have agile coaches (per team), agile leads (all teams' agile lead), scrum masters (the guy who does the meetings), and project owners (giving requirements), and lead project owners (planning) all trying to get developer time and attention. Right size this, OKR that, attend this attend that. Wasn't agile always about finding what works best for the team and doing it, with consideration of tracking what works well and what doesn't, and refining the process to fix it? Now it seems to be some sort of glorified job role, so even if the team get it right and run well they're patronised into attending non stop meetings from non technical staff trying to justify their jobs and whose own job role even states if the team is running well and self organising, then they need no involvement. All I hear these days is, how can we fix that? And the team answers; the delay is off team, in either third parties, business itself, or we've worked around the bits that we can. The dev team is now being asked to fix other teams' delay causing problems and then effectively silently shamed for not doing it week after week (because it gets raised again and again). This is end game and wasting time if you're team reaches this point, yet the coaches still pound that shaming in like there's something that can be done in team. Of course these meetings aren't meant to do that, but when has human psychology ever been considered (being asked how to fix something a dev has no control over is now a common theme in questions I'm asked)? IMHO agile in its current bastardised form should be taken out the back and shot. When it became a rigid set of rules (oh but "that's not how it's meant to be applied" is the war cry!) which promotes long term job roles preaching it, adds nothing to the teams' ability to adapt, and the team is already meeting most sprint goals and deliverables, the team has hit peak agility already.

TheBigSalad 3y ago
Why do people always say agile doesn't work and then tell some personal baggage story that clearly shows their company is doing it wrong. Is agile really to blame?
- ianis-h 3y ago
  Implementing true agile and keeping it clean of hiearchical management is so hard that it might not be the right choice for most companies... If something is to hard to implement, maybe it is the problem.

userbinator 3y ago

For a moment I thought this was about Windows XP, given the title and date... IMHO following any sort of methodology dogmatically is unlikely to give great results, and the best path is probably somewhere in between two extremes. Waterfall emphasises "plan ahead" --- a concept that seems to have completely disappeared from some types of software these days.

braza 3y ago

I was in the RUP universe for a period of my career and I would never want to go back on it agile was a refreshing breeze back then. However, the framework needs updates in several important areas: operations, data science, end of the PO figure and incorporating other actors as part of the feedback cycle, tech debt management, how to deal with uncertainty more efficiently, and so on. Unfortunately due to a lot of issues in our industry, agile got a lot of bad rep plus a lot of luggage it turns very hard to have a dispassionate discussion that the IQ of the participants does not drop 20%, at least. It's a shame, but I really would like to see some updates on this.

eschneider 3y ago
Fun fact: I worked at Rational for many years. We didn't even use RUP there.

jmclnx 3y ago

When I started out (80s), we would work closely with the real users and they got what the wanted. Back then development was text screens. Around 10 years later, some methodology came along and working with the users ended. This methodology was suppose to give the programmers more time to work. We ended up with frustrated users who started moving to Lotus 123 or Excel. Back then I developed (on the side) many processes where my users could get the data from the mainframe for use on their PCs. Agile came along later with prepackaged software, AMAPs(?), SAP, Oracle and many others that I have forgotten. Now we have many many users spending at least 50% of their time (some much more) testing upgrades instead of analyzing their data. End result, users are just doing what they can to get by whatever GUI screen is presented to them, not caring at all what data they are entering in. And most real work occurs in excel to the point where users are downloading gigs of data to their PC to get away from the canned, hard to use Enterprise Systems.

DrNosferatu 3y ago

Try building any high-stakes engineering project (say, a bridge, or a production operating system) like that… With Agile, at best, you will build an amateur treehouse. Sure, prototypes that test the viability of certain parts and aspects of the system are very useful. But having those prototypes and toy models then be “free-styled” (without a clear design document to be referenced - what exactly is the system supposed to do?) into a repurposed role to deliver the whole system’s functionality and reliability is the recipe to disaster. Or in other words: technical debt. - Where’s the Systems / Systems Integration perspective? - Where’s *Repeatability*? (middle management does like Agile to justify their many times useless positions) PS: I believe “Agile” explains a lot of the 737 MAX owes…

DrNosferatu 3y ago
The problem is that, in the software world, it’s very easy to disguise an amateur-quality treehouse as a high-stakes engineering project.

alberth 3y ago

Best Dev Methodology? What do people consider as the current best dev methodology?

taylodl 3y ago

I started my career back in the mid-80's and so I've lived with the process being described here. Kent Beck was a breath of fresh air and we all thought yes, this is what we've actually been doing! Mostly. Here's the thing: in some ways I think what we were doing back then was better. I just noted XP was essentially what we were doing anyway. Different teams and projects essentially chose their own internal methodology depending on what worked best for the project. Waterfall was what was presented to the project stakeholders. What does that mean? Paradoxically, we actually had more flexibility back then! Thanks to the tooling, which more or less standardizes the methodology, and all the Agile Coaches which have been trained on that tooling and standardized methodology - Agile today isn't very, well, agile - at least not from a development perspective. People point out that Agile allows for the requirements to change. No it doesn't. That's not a magic wand. Requirement changes still have project delivery impacts. Agile doesn't make that go away. It just provides for smaller iterations which facilitate the management of requirement changes. Know what? Iterative Waterfall, which we had been doing since the 80's (actual Waterfall is an artifact from the 70') also allowed for that. Now I live in a world of WaterScrumFall, which is absolutely the worst of all worlds.

michael1999 3y ago

Something people forget about the rise of agile is how many of the practices have become mainstream. Most shops I encountered 25 years ago: - had a manual build - deployed by hand - did all testing by hand - never touched code except for new features - might not even use source control But in the modern environment, we assume: - comprehensive source control, or even total BOM control - automated builds - automated tests - continuous integration - continuous refactoring - incremental design Congratulations, you are already doing half of XP! Those were all considered radical back in the day. What's left as purely "Agile" is the branded process stuff. E.g standardized meetings and titles like Scrum Master, SAF, etc. Given how prescriptive the business culture around it has become, it is a kind of anti-agile. So death to Agile, long live agile. Personally, I'm still an XP fiend at heart. Give me: a single list of prioritized work; a test suite I can trust that runs in < 15 minutes; and a dedicated team with good comms; and we'll tackle any problem you give us.

bluGill 3y ago
Most of those were considered normal best practice in watarfall shops I worked at. They were common, but we knew many not doing them and laughed at those fools.
subharmonicon 3y ago
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]

kitsune_ 3y ago

The main problem with the Agile industry is that the certificate mills give people the idea that they have to know nothing about software to work on/in software. Also Scrum as outlined by people like Jim Coplien would probably be kind of fine for certain set ups, but only a few agile coaches, POs or SMs know Scrum that well, instead it's a weird mix of apocryphal, illogical practices and superficial knowledge that, coupled with an inexperienced dev team, is similar to a giant Molotow cocktail that will sooner or later explode.

Pet_Ant 3y ago
Scrum is basically a set of necessary but not sufficient processes. I was sceptical about it, took the course, and aced the test. Scrum itself is like the rules for holding a good meeting. It's good common sense advice that I don't think you can actually reasonably object to. If it's not in the Scrum guide, it's not Scrum, truly find something objectionable in that: https://scrumguides.org/scrum-guide.html https://scrumguides.org/scrum-guide.html But in achieving that flawesseness, they made it so broad and vague that you really need to add additional practices to it. And then you got to be careful, mature, and thoughtful or else it's gonna turn into a shitshow... but if you just do Scrum you'll end up as a shitshow anyway. PS- to me personally the biggest flaw is that so much hinges on the definition of done being correct, and that is at least half the battle in dev and can almost single handedly save or sink an organisation in itself.

elzbardico 3y ago

Agile failed because it had a naive view point of politics. It never understood that the bureaucrat is the enemy and that the bureaucracy wouldn't give it up so easily. Instead, the bureaucracy did what does when it is threatened, it pretended to pay lip service to the agile principles while subverting them in order to survive and thrive.

stcredzero 3y ago
Agile failed because it had a naive view point of politics. It never understood that the bureaucrat is the enemy and that the bureaucracy wouldn't give it up so easily. Bureaucracy is just the human political animal expressing its awful nature in organizational systems. Instead, the bureaucracy did what does when it is threatened, it pretended to pay lip service to the agile principles while subverting them in order to survive and thrive. Amazing how Orwell never ceases to be relevant.

crabbone 3y ago

I want to reflect specifically on the testing part. Henrik Warne talks about how unit tests were an improvement to the development process, and how designing for testing was an improvement for program design. I think both are very naive ideas (as I think overall about Agile and XP). But, before I get to the "why" part, I want to first describe my perspective on how testing changed over time. The perspective on testing before the "shift left" happened was that testing is supposed to be adversarial. I.e. it was important that the testers don't know how the code works or what decisions did the development team make to solve higher-level problems the software was meant to solve. This was important so that testers wouldn't turn the blind eye to the software problems they would've otherwise gotten used to, or would have accepted the trade-offs before even getting into testing. The reason is very similar to how in clinical trials the participants aren't told whether they get placebo or the real drug. This is also why the testing would normally start after the software was in a shape ready for testing (i.e. after a reasonably long development interval). This is also why a lot of it was manual: there wouldn't have been time to develop utilities for testing since the testers didn't know what the software was like. But, of course, there were also commercial incentives to finish earlier. This is how "patch version" became a thing for example: a typical testing cycle would be to receive the system from the developers, to deploy it, to validate it (i.e. to ensure that the minimal required functionality is there), and then to try to "break" it. If the system broke, the developer would be notified. They then would have to fix the problems and deliver the fixes as patches. These patches then would be given a version number, and the testers would be required to use them to patch the deployed system in place, in order to continue testing. A system shipped to the customer would usually contain a bunch of patches, and the installation process would include patching as well. The downside of this system is the time it takes to get to the working product. The upside is the better overall quality of the product. The better quality comes from the testers working from specification rather than from their familiarity with the code. ---- So, unit tests. From the perspective of someone who had to manage CI for rather large organizations: unit tests give the least value for the most effort (among different test types). Because unit tests deal with the minutia of the code details they tend to change a lot, they grow stale very quickly, and they require a lot of maintenance because they tend to also multiply very quickly. Besides, most of the unit tests in every CI run test the code that didn't change anyways. They just burn electricity for no effect. It's very hard to come up with the system that would only apply unit tests where the code changed. In the end of the day, given the limited time and resources, if there's any test a developer should be spending their efforts on it's the end-to-end test. They don't change as often, and they at least can guarantee that the program, as a whole, works sometimes (unit tests have no useful guarantees about the whole program). ---- When it comes to designing for testing... it's also complicated. There are many dangers in doing this. Testing code is often a security backdoor. Testing code can also cause performance problems. There's a very delicate balance between the ways of how the system can be instrumented for testing and how much this instrumentation actually contributes to the quality of the system. My approach here is that as much as possible, the testing needs to be external to the system. This is to prevent tests from affecting the system, and especially from leaving undesirable artifacts in it. ---- Agile, or any other simplistic software development management process is just that: simplistic. It doesn't mean it "doesn't work" -- it means that it works sometimes. But, I wish we spent time on studying the process and discovering better way of doing things instead of trying to shoehorn things we meet in practice into existing simplistic process descriptions to justify their existence.

brailsafe 3y ago

I don't think I've ever been in a company that's used any Agile practice in an iterative fashion, or that's in any way thoughtful about structuring dev work. Managers adopt it as an arbitrary template for more compressed work, regardless of how well it fits into 2 weeks or 1-day standup cycles, then usually the same template permeates every other team, making it impossible to design a schedule that's appropriate out-of-sync with any other department or team. So I reduce the scope of my work to what can fit into 2 weeks and that I could have something tangible to speak about every single day, and there's no real feedback cycle engaged without a ton of friction and a raised eyebrow. I have a hard time believing that anything has ever shipped because the team chose Agile; any success determined only by deadlines, budget, and periodic (real) feedback cycles.