10 ms·

Modern Extreme Programming

166 points by henrik_w 12y ago

jay_kyburz 12y ago
Rock! I get the feeling there is some weird backlash against all things Agile lately. I've noticed it particularly in reddit comments. I suspect it's young people who just weren't around before Agile.
- makeitsuckless 12y ago
  You realize that Extreme Programming pre-dates Agile? XP was one of those things that prompted the creators to get together and formulate what they all had in common compared to traditional methods. This is what resulted in the Agile Manifesto. The backlash if mostly against the consultants and pointy-haired-bosses that cherry picked from various Agile practices the things they could grok, and implemented that as a cargo cult solution. In wider IT world, that cargo cult method has become known as "Agile", just like "hacker" now equals "cybercriminal" for the rest of the world.
- glibgil 12y ago
  Us old people hate Agile too.
  - dblohm7 12y ago
    Word!
  - jay_kyburz 12y ago
    Would you rather spend the first half of every project planning and scheduling every little feature, then spend the second half of the project missing deadlines and implementing features that are not right for the product?
    - Nursie 12y ago
      This seems to me a false dichotomy. Sometimes requirements actually are set in stone and it's good to do this - I worked on an embedded device last year, with fixed interfaces and fixed security requirements. That project would have gone a lot faster if there had been an effort to explore and document these at the beginning. --edit-- oh, and of course, agile projects never, ever miss deadlines...
    - MichaelGG 12y ago
      This is an incorrect comparison. But I'd also not like to work on a project where someone delivers a feature branch only to find out the feature's been redesigned completely for the 4th time. Or where there is no spec for features at all, just wireframes that change daily and developers are supposed to reverse engineer what the latest UI means into a feature set. But wait, daily standup so it's Agile. A lot of projects would do good to have a light approach at spec writing, to get faced with problems before they're in code. I'm unconvinced that a dev process is going to supersede dysfunctional technical management, no matter what we call it.
      - bottled_poe 12y ago
        Precisely. A team of decent engineers and competent managers will typically produce good software. And guess what - it will barely matter which methodology you choose to adopt.
        JoeAltmaier 12y ago
        A better dichotomy is: would you rather have a better process, or hire better engineers? I choose better engineers.
        s73v3r 12y ago
        Better engineers are expensive, and I can't crack the whip on them like I can disposable engineers. /phb
    - amyjess 12y ago
      I've worked on way too many projects where things went "Hey, you just delivered the big load to QA? Well, we think the customer wants features X, Y, and Z on top of what you've already written, but we're not budging on the release date, so you better pull the load from QA and start working 16-hour-days and coming in on weekends. Oh, and if it breaks after being delivered to the customer, we'll throw QA under the bus because QA failed to do proper soak testing, and we'll have QA throw you under the bus because you didn't give them time to soak since we're making you develop right up to the night before launch." to trust any process where features can be added after development begins.
- tsmarsh 12y ago
  I know what you are saying. I've been on sales calls, as an agile consultant, where we have deliberately dodged around the word. Its not just the new blood. My sense is that people were sold agile as a silver bullet, and it unsurprisingly under delivered. Even with Agile+XP you still get bugs, delays and budget misses, the difference is that you know about it much earlier, which, in my experience doesn't make people as happy as I hoped it would. I currently feel this way about Lisp too. I read the books, learned the basics, built stuff, even got a clojure job and, despite feeling better about my code, I'm struggling to provide measurable improvements over Java... but that doesn't mean I want to go back Java any more than I want to go back to 'not agile'.
- AYBABTME 12y ago
  Or just an overdose of agile consultancy crap.
- crdoconnor 12y ago
  I've noticed that Agile is frequently creatively misinterpreted as: * "move fast and break things" or * "testing is the end user's job" or * "what we were doing before, except with morning meetings where nobody is allowed to sit" I expect some of the backlash is, ironically, against that. It's similar to "devops" in this respect - a lot of people pretend to adopt the buzzword and then do almost the exact opposite of what it proscribes.
  - collyw 12y ago
    The thing is this style can work (well the first two anyway). Why spend two or three times as long coding tests for an in house application used by a few users and the requirements aren't actually known or well communicated? Developer time is often more expensive then the end user time.
    - crdoconnor 12y ago
      I used to think this too, but then I realized that this is actually backward thinking. It's quicker in the short and the long term to write tests. Every time you code (whether requirements are clear or not), you go through the following steps (often executed in the space of 2-3 minutes): 1) Think 2) Write code 3) Build/run code 4) Test and see the outcome 5) Go to step 1 Even if you are not writing tests, you are doing step 3 and 4. Moreover, if you are not writing tests, you are doing steps 3 and 4 manually. Manual is only quicker if there are a few of these iterations. If you are doing this iteration every 2-3 minutes, you will be doing it hundreds of times a day and thousands of times in total over the course of a project. Automating that process will save you a lot of time in the long run, and will still save you time in the short run, as well as leading to higher quality code.
      - michaelt 12y ago
        I think a lot of disagreement about TDD comes from the fact some things are a lot easier/quicker to test than others. If I'm writing a library to add two numbers, it's easy to create fast tests with no false alarms. Assert.equals(10, new BigDecimal(5).add(new BigDecimal(5)) - simple, fast, no false alarms, easy-to-maintain. Now imagine you're making a website and you want to test with multiple browsers, and it uses caching and connection pools and sessions and whatnot, and the website has several dozen pages, and there are a bunch of configuration options and feature flags and you need to test with all of them. Now all of a sudden you're administrating a pool of VMs with different OSes, writing web-scrapers, launching web servers every test cycle, waiting for tests of pages you haven't changed, running n tests * m pages * o server configurations * p clients, and all of a sudden you're spending more time keeping your tests working, or changing your software so tests run faster, and you're hardly spending any time working on features users want. Naturally, to someone writing the first type of software, unit testing seems perfectly logical. But I can also see how someone working on the second type of software might get frustrated!
- ternaryoperator 12y ago
  In Dr. Dobb's last year, Dave Thomas, one of the Pragmatic Progs and one of the original signers of the Agile Manifesto, railed against what Agile became[1] "Agile got immediately productized in many different ways. The whole point, to my mind, of the Agile Manifesto is that it's a set of personal practices that may scale to team level. You do not need a consultant to show you how to do that. It may help to have someone facilitate, but you do not need a consultant. And yet immediately what happened was that everyone and their dog hung out an Agile shingle and the whole thing turned into a branding exercise." [1] http://www.drdobbs.com/240166688 http://www.drdobbs.com/240166688
  - brudgers 12y ago
    Given enough time, any two-pizza-rule will prompt someone to the clever idea that leads to installing a giant pizza oven to accommodate 36 inch pizzas.
- Nursie 12y ago
  >> I suspect it's young people who just weren't around before Agile. I was around before Agile became the thing that everyone was doing. Myself and many of my contemporaries are very cynical about it because what it most often seems to boil down to "what we were doing before but with more meetings and heavier process". I've worked in places where Agile Evangelists would regularly take teams of people away from their desks for process-related meetings (retrospectives, planning, errr.... who the hell knows what else) for several hours at a time, more than once a week. I've heard Agile consultants say things like "And the great thing about Agile is that if you start falling behind, you can take what you have to the customer, involve them in the process, and deliver even more at the next sprint!" as if it would miraculously provide extra developer time/effort for free. And I've seen true-believers who seemed to think that if the project wasn't making progress then people probably just weren't doing 'Agile' hard enough, and probably needed even more meetings and process. I like the manifesto. I don't like what often actually gets applied out in the field, and the consultants/evangelists are basically cultists AFAICT.
  - BurningFrog 12y ago
    Weird. The kind of XP I've been involved in is near obsessive about maximizing programming time. Which means meetings are kept short, with minimum attendance.
    - Nursie 12y ago
      That sounds like doing it well, in accordance with principles, rather than doing it badly in accordance with consultants... --edit-- I wouldn't claim to know about XP, I've never worked somewhere that embraced XP specifically, just places that decided to go 'Agile' and then proceeded to bog themselves down in so much procedure that projects started to fail. I've only worked in one place where the morning stand-ups actually worked as they were intended - 5 developers go round the room, give a quick status and state any problems they have, identify who they need to talk to to get it solved, the get out again in under 10 minutes. Everywhere else I've worked they devolved into either developer chat/argument time or management info-broadcast time. For at least an hour. Every day. groan
- JustSomeNobody 12y ago
  It got MBA'd. It was turned into something that the MBAs can run reports from and hold people accountable. Now, I'm not anti-MBA. However, I do think that having people with engineering degrees be subordinate to people with MBAs is an outmoded business philosophy. They need to be more on par with one another.
- kzhahou 12y ago
  On the contrary: Agile is embraced by people (often young) who see is as a defense against the boogeyman WATERFALL that they think people had been following until now. In fact, few places did true waterfall, and even then it was not waterfall as originally intended with constant iteration and refinement. As a result, many teams now insistently follow agile with a strong belief that it's the only way to make progress. They don't accept that before daily standups, people were still capable of communicating when they were blocked. Before sprints, people still came in every day and cranked out code. Before kanban boards and backlogs, people called them todo lists and often did have them in a shared document. Before 1-2 hour sprint planning meetings, people still had a strong sense of the direction of their project and the steps needed to get to a shippable state. Agile defines units of work (the sprint, the story, etc) and sets up a fixed cadence for communication. It does not by itself create better code, better programmers, or better deliverables.
- s73v3r 12y ago
  Its because, quite frankly, most places suck at doing Agile. And they fully embrace most of the aspects of "Agile" that seem to be there only to treat devs as children and easily replaceable cogs. Most people's first exposure to Agile is in this kind of environment, and so they grow to resent it. Someone will undoubtedly come and reply to this saying that those places weren't really doing Agile, but that's irrelevant. They were claiming to do Agile, they paid some expensive consultants to train them on Agile, so from their perspective, they're Agile.
sz4kerto 12y ago
I'd try this continuous deployment thing in the finance or maybe in the automotive industry. Let's see how the clients enjoy it.
- iMark 12y ago
  The article differentiates between deployment and release.
- crdoconnor 12y ago
  Clients probably will enjoy it provided you have a comprehensive suite of automated tests that you ran before deploying.
  - sz4kerto 12y ago
    - "comprehensive suite": you can't mock everything. If you have an algorithmic trading platform, you connect to many 3rd parties and their systems are very complex, poorly documented and they don't work according to the documentation. - "automated tests": traders don't know what they want. They think they know, but they don't. And they will tell you things they don't want, and when you deliver them they'll be angry. - you don't have direct access to production. If something fails, you won't get all the logs because regulatory reasons. Sometimes you won't even get anything. - etc. I see the value of continuous deployment, just wanted to mention that it's not applicable in many-many fields outside of the CRUD bubble.
    - crdoconnor 12y ago
      This is profoundly ironic. Every excuse that you have made for not automating testing I have heard before ("mocking is hard. let's go shopping"). Most commonly, however, these excuses come from the pits of unprofessional software engineering, though - the "CRUD bubble" as you put it. I find it pretty funny that you think "customers who don't know what they want" is a problem that is unique to trading. Or poorly/wrongly documented APIs.
      - 12y ago
d--b 12y ago
Thanks for the mob programming concept. I always disliked pair programming, but I actually think that mob programming is a great idea! It sounds like a meeting where you actually get confronted with the reality of the code, and so you know where you have to make decisions both in terms of code design and product design. I'll definitely give it a shot
- noonespecial 12y ago
  Where I work, we grabbed an old(er) 50" TV and stuck it up on the wall in a common space. We gave it an old mini-itx and a wireless keyboard/trackpad. Just enough for a browser, XFCE and Sublime. Now we gather around it and yell at the code like its a football game and toss the keyboard back and forth. Not for every project or team but recommend it way more than I thought I would at first. We do need to find a way to nerf the keyboard.
  - lmm 12y ago
    You could give everyone a bluetooth keyboard, so that no-one "has the keyboard" and it's all collaborative all the time.
    - noonespecial 12y ago
      We rather enjoy the "Conch in Lord of the Flies" vibe the current setup imparts.
pjc50 12y ago
I can't tell if this is a spoof or not.
- M8 12y ago
  A bit religious, but honest. Just needs to dial down the TDD-preaching - it's not a silver bullet.
  - shele 12y ago
    A tale: http://alistair.cockburn.us/Thinking+before+programming http://alistair.cockburn.us/Thinking+before+programming
  - pjc50 12y ago
    The "mob programming" was the thing that made it hard to take seriously. All the downsides of meetings (bikeshedding, grandstanding, high (time x money) consumption) without time and space to think. I currently work with what https://news.ycombinator.com/item?id=9413117 https://news.ycombinator.com/item?id=9413117 calls "implied pair programming": code reviews before commit. But the rapid build and rapid deploy is so incredibly far from what's achievable here (C++/WinCE land). A quick build takes about 15 minutes. A full all-target-platforms build takes about 3 hours. It's then merged with releases from other teams and handed to QA. Customers are using releases up to three years old.
- untog 12y ago
  This is the first I've heard of "extreme programming". Coupled with "dialing it up to 11" it all sounds like pseudo-masochistic nonsense to me, but apparently it's very real.
catmanjan 12y ago
How does this fit into an environment with a large tester presence?
Flimm 12y ago
I would say that we are moving similarly, and I like the way Benji Weber put it: - From continuous integration to continuous deployment - To project ownership (although there is some resistance here on the part of some software devs, who don't feel it's their responsibility) - Monitoring first: we have a strong desire to increase this but we're a bit at a loss as to what a good light-weight solution is here The only exception is mob programming. Instead, we still have developers code on their own, and we switch to pair programming when troubleshooting a tricky issue.
- bbrazil 12y ago
  > Monitoring first: we have a strong desire to increase this but we're a bit at a loss as to what a good light-weight solution is here Prometheus is designed with this in mind. Instrumentation is easy to add and takes care of things like concurrency and state maintenance for you, so you can sprinkle it anywhere safely. http://www.slideshare.net/brianbrazil/python-ireland-monitoring-your-python-with-prometheus http://www.slideshare.net/brianbrazil/python-ireland-monitor... goes into this a bit more.
- SideburnsOfDoom 12y ago
  You could pay for a NewRelic account, or invest the time in getting statsd+graphite or Riemann infrastructure set up. There are other systems too; it's a growth area. "Monitoring-First Programming" to me means that monitoring and capturing errors in production is very valuable indeed. It's not a reason to abandon regular testing activities, but it is basically the same kind of thing as testing. Links: http://newrelic.com/ http://newrelic.com/ http://www.kinvey.com/blog/89/how-to-set-up-metric-collection-using-graphite-and-statsd-on-ubuntu-1204-lts http://www.kinvey.com/blog/89/how-to-set-up-metric-collectio... http://riemann.io/ http://riemann.io/
  - falcolas 12y ago
    I believe it's a mistake to put Riemann in the same sentence as statsd/graphite. It really does not try and solve the same problems, it's more focused on alerting than trend analysis. In fact it recommends pushing data out of Riemann and into Graphite to perform long term trend analysis. That said, if you have the time to invest in grokking Riemann (learn Clojure first), it would be a fantastic tool to base the rest of your monitoring infrastructure upon.
fsloth 12y ago
I've done my best programming toiling first with paper and pens for a few weeks, slowly reducing the spaghetti domain requirements into an elegant graph formalism that has proven to be understandable and extensible. After the code was in place pair programming was a fantastic way to share understanding of the code. This mandatory XP really is not suitable for all environments.
kriro 12y ago
I never did pair-programming but I really liked the implied pair programming that resulted from having a checkin-partner that had to review and greenlight your commits. After sending the request you'd walk over and talk about the code for a bit. Usually pretty informally (over a coffee or water if there were a lot of commits :P). It usually went "ok tell me what your code does" and then some talk about details, design tradeofs, identified issues. Sometimes there was a rubber ducking effect of sorts where you figured out an issue with the overall code design but the major benefit was that it forced you to write code that is not too long and can be reasoned about "in a vacuum" (kind of). Second major benefit was that it forced you to physically walk away from the computer which has all kinds of benefits. All informal, nothing set in stone. We just used IM-DND to indicate that you shouldn't walk over just now because I'm in a no-disturbe mode of coding. You can probably bundle it up, write fancy DND/checkin-greenlight software and brand it as "Coffee cup driven software development". Agile and at least 4.0 ;P
- gedrap 12y ago
  I've done that for non-trivial commits and found it much better than someone reviewing a commit alone. When you are reviewing a commit alone, it's very easy to just skim through and not be aware of details.
- rudimental 12y ago
  The social aspect makes coding more fun. And getting away from your keyboard is great. What you're describing to me sounds like informal code review, a high level walkthroughs of what your code does and what choices you made and why. It's a taste of pair programming. Talking through your code is great. Implied pair programming sounds about right. Try the full thing sometime!
- ecoffey 12y ago
  Let's say the D represents the duration between when you typed that code, and when you got feedback informally at the watercooler. Pair programming, when it's working well, is just lim(D -> 0) :)
ascotan 12y ago
I think I've realized over the years that this kind of development process lends itself to certain kinds of software. In particular XP is effective for web server products. Not all software can or should be deployed rapidly like this. It's been my experience that end users don't really want constant churn in their software unless it's transparent to them. It's also hard to justify having 11 SEs sitting around a monitor programming. Their combined rate is probably something like 2million a year with overhead. with that kind of burn rate you'd better have some serious productivity from the 1 guy on the keyboard.
- lighthawk 12y ago
  > In particular XP is effective for web server products. I was on a team that used it effectively to develop a Java back-end framework, which was not web services nor hosted by a web server. While I agree not everything fits into XP, you can't classify it like that. Mob programming is not classical XP, but it is in the same spirit of pair programming. It can burn a lot of money per feature developed and LOC written, you need to also consider the mentoring/learning aspect of it. Same goes with pair programming. It isn't only about code quality. It is about mentoring/sharing/learning. Don't get me wrong- if you've never pair programmed for a long time before, you don't know really understand the meaning of the word "annoyance", and if you don't have the right setup, one person may zone-out and not really be helping. Doing it right is an art. If you learn a way to do it correctly, it will really help: your developers will be more productive because they learn from each other, there will be less churn resulting from any formal code reviews that might be required if you need formal sign-off (if required at all) and there will be fewer bugs. Fewer bugs mean: less work for helpdesk/customer service, fewer adversely affected users within the company, fewer periods when you aren't taking orders/etc. which cause lost revenue and customer frustration which can lead to them telling others about their bad experience and losing additional opportunities, etc. But, odds are unless you try things out, tune them, try again, no matter what methodology you choose, you're going to get something wrong. It doesn't matter what you are developing. Hone it.
- falcolas 12y ago
  I agree with this. Of late I've actually become a bit annoyed with our Slack install, because it keeps changing. What can and can't I do with our chat tool? Who knows! It'll be different tomorrow. I used to lambast my colleagues for having chosen to use IRC over more modern tools like Jabber or Hangouts. I realize now how foolish I was. Some software just don't need to change continuously.
DanielBMarkham 12y ago
Sadly, I feel that most Agile/XP posts are mis-informed rants, but this essay was really good. It covers many of the changes that are happening. Especially noteworthy for folks who haven't checked into Agile/XP for a while are "Collective Code-Ownership becomes Collective Product-Ownership" and "Test-First Programming becomes Monitoring-First Programming" Yes, there's a ton of folks who are lost in the woods when it comes to all of this, but there are also a heckuva lot of folks that are taking it to the next level. It's really cool to see the community evolving.
alricb 12y ago
XProlo? Extreme Proletarians? So they like, eXtremely don't own the means of production?
- civilframe 12y ago
  I see what you did there :-)
dep_b 12y ago
I once worked at a place that had pair programming as a rule as well. Fix button size CSS for IE6? Two programmers, one computer. Change First Name, Last Name to First Name Last Name? Two programmers, one computer. Being stuck on something totally trivial yet essential where you depend on someone else? Two people sitting on their hands instead of one. So this is what it ended up being: one guy doing the work or sending HipChat messages to the guy required to get unstuck while the other one was browsing Facebook. Then in the end the guy that was picking his nose all the time looks at the other guy's work quickly and you say "yeah....that seems about right....merge it!". Sure I can imagine it's great to work out the architecture of your new framework together with a few guys and a whiteboard and then starting to work on the code together. But why would somebody need to watch how you're doing some kind of trivial CRUD? Unless literally every problem and feature they're doing is super exciting sooner or later somebody is just colouring between the lines to get the application finished and a quick code review when it's time to merge the pull request is all you need.
- trcollinson 12y ago
  I am an advocate of paired programming. A lot of organizations do it really poorly. Your examples show exactly where it does not work. First off, sometimes you have a bunch of minor tasks that need to be taken care of, like updating some text in the UI or fixing a button size, also in the UI. Is there a reason that you have to sit down and plan to only do that? If you have a well prioritized backlog and the freedom to get work done these scenario's should be more like: "Let's work on adding this new feature here." "Ok that's a good one, we'll need to do a, b, and c to get it all wired up, working and tested. Hey since we're in that part of the code there are some small tasks about changing the button size and the text here, let's make sure to get those done." ... "Great! we completed the new feature, fixed the button size, and the text. Merge it!" I never sat down with my pair for the day and said "Ok go fix that button. Great, merge that. What's next?" It was always a discussion of the most valuable thing to get done and any collateral issues that could also be fixed. In this case, we often got more done. Second, if you had a pair partner sitting around doing nothing, there is a problem. They aren't engaged. They either need to become engaged or not be in an environment where there is paired programming. That is ok! But they need to admit it and move on. Pairing works well if you have the people and processes in place to allow it to work well. If there are people sitting on their hands, then there is a problem. Though I would argue that if you took away paired programming, the same engineers would often still be sitting on their hands, playing on facebook.
lolok 12y ago
lol?

166 points by henrik_w 12y ago

Rock! I get the feeling there is some weird backlash against all things Agile lately. I've noticed it particularly in reddit comments. I suspect it's young people who just weren't around before Agile.

makeitsuckless 12y ago
You realize that Extreme Programming pre-dates Agile? XP was one of those things that prompted the creators to get together and formulate what they all had in common compared to traditional methods. This is what resulted in the Agile Manifesto. The backlash if mostly against the consultants and pointy-haired-bosses that cherry picked from various Agile practices the things they could grok, and implemented that as a cargo cult solution. In wider IT world, that cargo cult method has become known as "Agile", just like "hacker" now equals "cybercriminal" for the rest of the world.
glibgil 12y ago
Us old people hate Agile too.
- dblohm7 12y ago
  Word!
- jay_kyburz 12y ago
  Would you rather spend the first half of every project planning and scheduling every little feature, then spend the second half of the project missing deadlines and implementing features that are not right for the product?
  - Nursie 12y ago
    This seems to me a false dichotomy. Sometimes requirements actually are set in stone and it's good to do this - I worked on an embedded device last year, with fixed interfaces and fixed security requirements. That project would have gone a lot faster if there had been an effort to explore and document these at the beginning. --edit-- oh, and of course, agile projects never, ever miss deadlines...
  - MichaelGG 12y ago
    This is an incorrect comparison. But I'd also not like to work on a project where someone delivers a feature branch only to find out the feature's been redesigned completely for the 4th time. Or where there is no spec for features at all, just wireframes that change daily and developers are supposed to reverse engineer what the latest UI means into a feature set. But wait, daily standup so it's Agile. A lot of projects would do good to have a light approach at spec writing, to get faced with problems before they're in code. I'm unconvinced that a dev process is going to supersede dysfunctional technical management, no matter what we call it.
    - bottled_poe 12y ago
      Precisely. A team of decent engineers and competent managers will typically produce good software. And guess what - it will barely matter which methodology you choose to adopt.
      - JoeAltmaier 12y ago
        A better dichotomy is: would you rather have a better process, or hire better engineers? I choose better engineers.
        s73v3r 12y ago
        Better engineers are expensive, and I can't crack the whip on them like I can disposable engineers. /phb
  - amyjess 12y ago
    I've worked on way too many projects where things went "Hey, you just delivered the big load to QA? Well, we think the customer wants features X, Y, and Z on top of what you've already written, but we're not budging on the release date, so you better pull the load from QA and start working 16-hour-days and coming in on weekends. Oh, and if it breaks after being delivered to the customer, we'll throw QA under the bus because QA failed to do proper soak testing, and we'll have QA throw you under the bus because you didn't give them time to soak since we're making you develop right up to the night before launch." to trust any process where features can be added after development begins.
tsmarsh 12y ago
I know what you are saying. I've been on sales calls, as an agile consultant, where we have deliberately dodged around the word. Its not just the new blood. My sense is that people were sold agile as a silver bullet, and it unsurprisingly under delivered. Even with Agile+XP you still get bugs, delays and budget misses, the difference is that you know about it much earlier, which, in my experience doesn't make people as happy as I hoped it would. I currently feel this way about Lisp too. I read the books, learned the basics, built stuff, even got a clojure job and, despite feeling better about my code, I'm struggling to provide measurable improvements over Java... but that doesn't mean I want to go back Java any more than I want to go back to 'not agile'.
AYBABTME 12y ago
Or just an overdose of agile consultancy crap.
crdoconnor 12y ago
I've noticed that Agile is frequently creatively misinterpreted as: * "move fast and break things" or * "testing is the end user's job" or * "what we were doing before, except with morning meetings where nobody is allowed to sit" I expect some of the backlash is, ironically, against that. It's similar to "devops" in this respect - a lot of people pretend to adopt the buzzword and then do almost the exact opposite of what it proscribes.
- collyw 12y ago
  The thing is this style can work (well the first two anyway). Why spend two or three times as long coding tests for an in house application used by a few users and the requirements aren't actually known or well communicated? Developer time is often more expensive then the end user time.
  - crdoconnor 12y ago
    I used to think this too, but then I realized that this is actually backward thinking. It's quicker in the short and the long term to write tests. Every time you code (whether requirements are clear or not), you go through the following steps (often executed in the space of 2-3 minutes): 1) Think 2) Write code 3) Build/run code 4) Test and see the outcome 5) Go to step 1 Even if you are not writing tests, you are doing step 3 and 4. Moreover, if you are not writing tests, you are doing steps 3 and 4 manually. Manual is only quicker if there are a few of these iterations. If you are doing this iteration every 2-3 minutes, you will be doing it hundreds of times a day and thousands of times in total over the course of a project. Automating that process will save you a lot of time in the long run, and will still save you time in the short run, as well as leading to higher quality code.
    - michaelt 12y ago
      I think a lot of disagreement about TDD comes from the fact some things are a lot easier/quicker to test than others. If I'm writing a library to add two numbers, it's easy to create fast tests with no false alarms. Assert.equals(10, new BigDecimal(5).add(new BigDecimal(5)) - simple, fast, no false alarms, easy-to-maintain. Now imagine you're making a website and you want to test with multiple browsers, and it uses caching and connection pools and sessions and whatnot, and the website has several dozen pages, and there are a bunch of configuration options and feature flags and you need to test with all of them. Now all of a sudden you're administrating a pool of VMs with different OSes, writing web-scrapers, launching web servers every test cycle, waiting for tests of pages you haven't changed, running n tests * m pages * o server configurations * p clients, and all of a sudden you're spending more time keeping your tests working, or changing your software so tests run faster, and you're hardly spending any time working on features users want. Naturally, to someone writing the first type of software, unit testing seems perfectly logical. But I can also see how someone working on the second type of software might get frustrated!
ternaryoperator 12y ago
In Dr. Dobb's last year, Dave Thomas, one of the Pragmatic Progs and one of the original signers of the Agile Manifesto, railed against what Agile became[1] "Agile got immediately productized in many different ways. The whole point, to my mind, of the Agile Manifesto is that it's a set of personal practices that may scale to team level. You do not need a consultant to show you how to do that. It may help to have someone facilitate, but you do not need a consultant. And yet immediately what happened was that everyone and their dog hung out an Agile shingle and the whole thing turned into a branding exercise." [1] http://www.drdobbs.com/240166688 http://www.drdobbs.com/240166688
- brudgers 12y ago
  Given enough time, any two-pizza-rule will prompt someone to the clever idea that leads to installing a giant pizza oven to accommodate 36 inch pizzas.
Nursie 12y ago
>> I suspect it's young people who just weren't around before Agile. I was around before Agile became the thing that everyone was doing. Myself and many of my contemporaries are very cynical about it because what it most often seems to boil down to "what we were doing before but with more meetings and heavier process". I've worked in places where Agile Evangelists would regularly take teams of people away from their desks for process-related meetings (retrospectives, planning, errr.... who the hell knows what else) for several hours at a time, more than once a week. I've heard Agile consultants say things like "And the great thing about Agile is that if you start falling behind, you can take what you have to the customer, involve them in the process, and deliver even more at the next sprint!" as if it would miraculously provide extra developer time/effort for free. And I've seen true-believers who seemed to think that if the project wasn't making progress then people probably just weren't doing 'Agile' hard enough, and probably needed even more meetings and process. I like the manifesto. I don't like what often actually gets applied out in the field, and the consultants/evangelists are basically cultists AFAICT.
- BurningFrog 12y ago
  Weird. The kind of XP I've been involved in is near obsessive about maximizing programming time. Which means meetings are kept short, with minimum attendance.
  - Nursie 12y ago
    That sounds like doing it well, in accordance with principles, rather than doing it badly in accordance with consultants... --edit-- I wouldn't claim to know about XP, I've never worked somewhere that embraced XP specifically, just places that decided to go 'Agile' and then proceeded to bog themselves down in so much procedure that projects started to fail. I've only worked in one place where the morning stand-ups actually worked as they were intended - 5 developers go round the room, give a quick status and state any problems they have, identify who they need to talk to to get it solved, the get out again in under 10 minutes. Everywhere else I've worked they devolved into either developer chat/argument time or management info-broadcast time. For at least an hour. Every day. groan
JustSomeNobody 12y ago
It got MBA'd. It was turned into something that the MBAs can run reports from and hold people accountable. Now, I'm not anti-MBA. However, I do think that having people with engineering degrees be subordinate to people with MBAs is an outmoded business philosophy. They need to be more on par with one another.
kzhahou 12y ago
On the contrary: Agile is embraced by people (often young) who see is as a defense against the boogeyman WATERFALL that they think people had been following until now. In fact, few places did true waterfall, and even then it was not waterfall as originally intended with constant iteration and refinement. As a result, many teams now insistently follow agile with a strong belief that it's the only way to make progress. They don't accept that before daily standups, people were still capable of communicating when they were blocked. Before sprints, people still came in every day and cranked out code. Before kanban boards and backlogs, people called them todo lists and often did have them in a shared document. Before 1-2 hour sprint planning meetings, people still had a strong sense of the direction of their project and the steps needed to get to a shippable state. Agile defines units of work (the sprint, the story, etc) and sets up a fixed cadence for communication. It does not by itself create better code, better programmers, or better deliverables.
s73v3r 12y ago
Its because, quite frankly, most places suck at doing Agile. And they fully embrace most of the aspects of "Agile" that seem to be there only to treat devs as children and easily replaceable cogs. Most people's first exposure to Agile is in this kind of environment, and so they grow to resent it. Someone will undoubtedly come and reply to this saying that those places weren't really doing Agile, but that's irrelevant. They were claiming to do Agile, they paid some expensive consultants to train them on Agile, so from their perspective, they're Agile.

sz4kerto 12y ago

I'd try this continuous deployment thing in the finance or maybe in the automotive industry. Let's see how the clients enjoy it.

iMark 12y ago
The article differentiates between deployment and release.
crdoconnor 12y ago
Clients probably will enjoy it provided you have a comprehensive suite of automated tests that you ran before deploying.
- sz4kerto 12y ago
  - "comprehensive suite": you can't mock everything. If you have an algorithmic trading platform, you connect to many 3rd parties and their systems are very complex, poorly documented and they don't work according to the documentation. - "automated tests": traders don't know what they want. They think they know, but they don't. And they will tell you things they don't want, and when you deliver them they'll be angry. - you don't have direct access to production. If something fails, you won't get all the logs because regulatory reasons. Sometimes you won't even get anything. - etc. I see the value of continuous deployment, just wanted to mention that it's not applicable in many-many fields outside of the CRUD bubble.
  - crdoconnor 12y ago
    This is profoundly ironic. Every excuse that you have made for not automating testing I have heard before ("mocking is hard. let's go shopping"). Most commonly, however, these excuses come from the pits of unprofessional software engineering, though - the "CRUD bubble" as you put it. I find it pretty funny that you think "customers who don't know what they want" is a problem that is unique to trading. Or poorly/wrongly documented APIs.
    - 12y ago

d--b 12y ago

Thanks for the mob programming concept. I always disliked pair programming, but I actually think that mob programming is a great idea! It sounds like a meeting where you actually get confronted with the reality of the code, and so you know where you have to make decisions both in terms of code design and product design. I'll definitely give it a shot

noonespecial 12y ago
Where I work, we grabbed an old(er) 50" TV and stuck it up on the wall in a common space. We gave it an old mini-itx and a wireless keyboard/trackpad. Just enough for a browser, XFCE and Sublime. Now we gather around it and yell at the code like its a football game and toss the keyboard back and forth. Not for every project or team but recommend it way more than I thought I would at first. We do need to find a way to nerf the keyboard.
- lmm 12y ago
  You could give everyone a bluetooth keyboard, so that no-one "has the keyboard" and it's all collaborative all the time.
  - noonespecial 12y ago
    We rather enjoy the "Conch in Lord of the Flies" vibe the current setup imparts.

pjc50 12y ago

I can't tell if this is a spoof or not.

M8 12y ago
A bit religious, but honest. Just needs to dial down the TDD-preaching - it's not a silver bullet.
- shele 12y ago
  A tale: http://alistair.cockburn.us/Thinking+before+programming http://alistair.cockburn.us/Thinking+before+programming
- pjc50 12y ago
  The "mob programming" was the thing that made it hard to take seriously. All the downsides of meetings (bikeshedding, grandstanding, high (time x money) consumption) without time and space to think. I currently work with what https://news.ycombinator.com/item?id=9413117 https://news.ycombinator.com/item?id=9413117 calls "implied pair programming": code reviews before commit. But the rapid build and rapid deploy is so incredibly far from what's achievable here (C++/WinCE land). A quick build takes about 15 minutes. A full all-target-platforms build takes about 3 hours. It's then merged with releases from other teams and handed to QA. Customers are using releases up to three years old.
untog 12y ago
This is the first I've heard of "extreme programming". Coupled with "dialing it up to 11" it all sounds like pseudo-masochistic nonsense to me, but apparently it's very real.

catmanjan 12y ago

How does this fit into an environment with a large tester presence?

Flimm 12y ago

I would say that we are moving similarly, and I like the way Benji Weber put it: - From continuous integration to continuous deployment - To project ownership (although there is some resistance here on the part of some software devs, who don't feel it's their responsibility) - Monitoring first: we have a strong desire to increase this but we're a bit at a loss as to what a good light-weight solution is here The only exception is mob programming. Instead, we still have developers code on their own, and we switch to pair programming when troubleshooting a tricky issue.

bbrazil 12y ago
> Monitoring first: we have a strong desire to increase this but we're a bit at a loss as to what a good light-weight solution is here Prometheus is designed with this in mind. Instrumentation is easy to add and takes care of things like concurrency and state maintenance for you, so you can sprinkle it anywhere safely. http://www.slideshare.net/brianbrazil/python-ireland-monitoring-your-python-with-prometheus http://www.slideshare.net/brianbrazil/python-ireland-monitor... goes into this a bit more.
SideburnsOfDoom 12y ago
You could pay for a NewRelic account, or invest the time in getting statsd+graphite or Riemann infrastructure set up. There are other systems too; it's a growth area. "Monitoring-First Programming" to me means that monitoring and capturing errors in production is very valuable indeed. It's not a reason to abandon regular testing activities, but it is basically the same kind of thing as testing. Links: http://newrelic.com/ http://newrelic.com/ http://www.kinvey.com/blog/89/how-to-set-up-metric-collection-using-graphite-and-statsd-on-ubuntu-1204-lts http://www.kinvey.com/blog/89/how-to-set-up-metric-collectio... http://riemann.io/ http://riemann.io/
- falcolas 12y ago
  I believe it's a mistake to put Riemann in the same sentence as statsd/graphite. It really does not try and solve the same problems, it's more focused on alerting than trend analysis. In fact it recommends pushing data out of Riemann and into Graphite to perform long term trend analysis. That said, if you have the time to invest in grokking Riemann (learn Clojure first), it would be a fantastic tool to base the rest of your monitoring infrastructure upon.

fsloth 12y ago

I've done my best programming toiling first with paper and pens for a few weeks, slowly reducing the spaghetti domain requirements into an elegant graph formalism that has proven to be understandable and extensible. After the code was in place pair programming was a fantastic way to share understanding of the code. This mandatory XP really is not suitable for all environments.

kriro 12y ago

I never did pair-programming but I really liked the implied pair programming that resulted from having a checkin-partner that had to review and greenlight your commits. After sending the request you'd walk over and talk about the code for a bit. Usually pretty informally (over a coffee or water if there were a lot of commits :P). It usually went "ok tell me what your code does" and then some talk about details, design tradeofs, identified issues. Sometimes there was a rubber ducking effect of sorts where you figured out an issue with the overall code design but the major benefit was that it forced you to write code that is not too long and can be reasoned about "in a vacuum" (kind of). Second major benefit was that it forced you to physically walk away from the computer which has all kinds of benefits. All informal, nothing set in stone. We just used IM-DND to indicate that you shouldn't walk over just now because I'm in a no-disturbe mode of coding. You can probably bundle it up, write fancy DND/checkin-greenlight software and brand it as "Coffee cup driven software development". Agile and at least 4.0 ;P

gedrap 12y ago
I've done that for non-trivial commits and found it much better than someone reviewing a commit alone. When you are reviewing a commit alone, it's very easy to just skim through and not be aware of details.
rudimental 12y ago
The social aspect makes coding more fun. And getting away from your keyboard is great. What you're describing to me sounds like informal code review, a high level walkthroughs of what your code does and what choices you made and why. It's a taste of pair programming. Talking through your code is great. Implied pair programming sounds about right. Try the full thing sometime!
ecoffey 12y ago
Let's say the D represents the duration between when you typed that code, and when you got feedback informally at the watercooler. Pair programming, when it's working well, is just lim(D -> 0) :)

ascotan 12y ago

I think I've realized over the years that this kind of development process lends itself to certain kinds of software. In particular XP is effective for web server products. Not all software can or should be deployed rapidly like this. It's been my experience that end users don't really want constant churn in their software unless it's transparent to them. It's also hard to justify having 11 SEs sitting around a monitor programming. Their combined rate is probably something like 2million a year with overhead. with that kind of burn rate you'd better have some serious productivity from the 1 guy on the keyboard.

lighthawk 12y ago
> In particular XP is effective for web server products. I was on a team that used it effectively to develop a Java back-end framework, which was not web services nor hosted by a web server. While I agree not everything fits into XP, you can't classify it like that. Mob programming is not classical XP, but it is in the same spirit of pair programming. It can burn a lot of money per feature developed and LOC written, you need to also consider the mentoring/learning aspect of it. Same goes with pair programming. It isn't only about code quality. It is about mentoring/sharing/learning. Don't get me wrong- if you've never pair programmed for a long time before, you don't know really understand the meaning of the word "annoyance", and if you don't have the right setup, one person may zone-out and not really be helping. Doing it right is an art. If you learn a way to do it correctly, it will really help: your developers will be more productive because they learn from each other, there will be less churn resulting from any formal code reviews that might be required if you need formal sign-off (if required at all) and there will be fewer bugs. Fewer bugs mean: less work for helpdesk/customer service, fewer adversely affected users within the company, fewer periods when you aren't taking orders/etc. which cause lost revenue and customer frustration which can lead to them telling others about their bad experience and losing additional opportunities, etc. But, odds are unless you try things out, tune them, try again, no matter what methodology you choose, you're going to get something wrong. It doesn't matter what you are developing. Hone it.
falcolas 12y ago
I agree with this. Of late I've actually become a bit annoyed with our Slack install, because it keeps changing. What can and can't I do with our chat tool? Who knows! It'll be different tomorrow. I used to lambast my colleagues for having chosen to use IRC over more modern tools like Jabber or Hangouts. I realize now how foolish I was. Some software just don't need to change continuously.

DanielBMarkham 12y ago

Sadly, I feel that most Agile/XP posts are mis-informed rants, but this essay was really good. It covers many of the changes that are happening. Especially noteworthy for folks who haven't checked into Agile/XP for a while are "Collective Code-Ownership becomes Collective Product-Ownership" and "Test-First Programming becomes Monitoring-First Programming" Yes, there's a ton of folks who are lost in the woods when it comes to all of this, but there are also a heckuva lot of folks that are taking it to the next level. It's really cool to see the community evolving.

alricb 12y ago

XProlo? Extreme Proletarians? So they like, eXtremely don't own the means of production?

civilframe 12y ago
I see what you did there :-)

dep_b 12y ago

I once worked at a place that had pair programming as a rule as well. Fix button size CSS for IE6? Two programmers, one computer. Change First Name, Last Name to First Name Last Name? Two programmers, one computer. Being stuck on something totally trivial yet essential where you depend on someone else? Two people sitting on their hands instead of one. So this is what it ended up being: one guy doing the work or sending HipChat messages to the guy required to get unstuck while the other one was browsing Facebook. Then in the end the guy that was picking his nose all the time looks at the other guy's work quickly and you say "yeah....that seems about right....merge it!". Sure I can imagine it's great to work out the architecture of your new framework together with a few guys and a whiteboard and then starting to work on the code together. But why would somebody need to watch how you're doing some kind of trivial CRUD? Unless literally every problem and feature they're doing is super exciting sooner or later somebody is just colouring between the lines to get the application finished and a quick code review when it's time to merge the pull request is all you need.

trcollinson 12y ago
I am an advocate of paired programming. A lot of organizations do it really poorly. Your examples show exactly where it does not work. First off, sometimes you have a bunch of minor tasks that need to be taken care of, like updating some text in the UI or fixing a button size, also in the UI. Is there a reason that you have to sit down and plan to only do that? If you have a well prioritized backlog and the freedom to get work done these scenario's should be more like: "Let's work on adding this new feature here." "Ok that's a good one, we'll need to do a, b, and c to get it all wired up, working and tested. Hey since we're in that part of the code there are some small tasks about changing the button size and the text here, let's make sure to get those done." ... "Great! we completed the new feature, fixed the button size, and the text. Merge it!" I never sat down with my pair for the day and said "Ok go fix that button. Great, merge that. What's next?" It was always a discussion of the most valuable thing to get done and any collateral issues that could also be fixed. In this case, we often got more done. Second, if you had a pair partner sitting around doing nothing, there is a problem. They aren't engaged. They either need to become engaged or not be in an environment where there is paired programming. That is ok! But they need to admit it and move on. Pairing works well if you have the people and processes in place to allow it to work well. If there are people sitting on their hands, then there is a problem. Though I would argue that if you took away paired programming, the same engineers would often still be sitting on their hands, playing on facebook.

lolok 12y ago

lol?