
Modern Extreme Programming - henrik_w
http://benjiweber.co.uk/blog/2015/04/17/modern-extreme-programming/
======
kriro
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

~~~
rudimental
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!

------
dep_b
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
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.

------
ascotan
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.

~~~
iopq
What? That's like saying that programming is easy because it's just typing.

It's not about how fast the guy with the monitor writes things! It's about
making the right choice when you're designing a system.

When I do programming by myself I go through many designs and refactorings.

If someone already mentioned "hey, don't allocate on the hot path" and "make a
closure here instead of copy pasting" and so forth without me having to be
concerned about code quality and performance I'd get things done faster. I
usually implement a very naive first version. If after typing this up I
already have 3-4 people fixing it, then my pull request can have good
performance, style, etc. from the get-go and get merged pretty fast instead of
constant "can you fix this, then I'll merge it?"

~~~
lojack
I think we can all agree that the keyboard isn't the limiting factor here.

Individual programmers at their own keyboards can all focus on separate
problems. Two (or more) programmers with a single keyboard can only focus on a
single problem at a time, but they get the experience and perspective of
multiple developers. It's really just a matter of breadth of focus vs depth of
focus.

At a certain point adding more developers won't help and it will end up
wasting resources. This may be as soon as you add a second developer, or maybe
after you add 6 developers.

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

~~~
M8
A bit religious, but honest. Just needs to dial down the TDD-preaching - it's
not a silver bullet.

~~~
pjc50
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.

------
Flimm
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.

~~~
SideburnsOfDoom
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-
collectio...](http://www.kinvey.com/blog/89/how-to-set-up-metric-collection-
using-graphite-and-statsd-on-ubuntu-1204-lts)

[http://riemann.io/](http://riemann.io/)

~~~
falcolas
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.

~~~
SideburnsOfDoom
You are right, sorry if it wasn't clear - I had in mind Riemann as a
replacement for the statsd part of that duo. That's how I've seen it used but
my knowledge and experience are limited.

------
d--b
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
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
You could give everyone a bluetooth keyboard, so that no-one "has the
keyboard" and it's all collaborative all the time.

~~~
noonespecial
We rather enjoy the "Conch in Lord of the Flies" vibe the current setup
imparts.

------
jay_kyburz
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.

~~~
crdoconnor
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
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
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
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!

~~~
mdellabitta
I wouldn't call your second case unit testing, but rather integration testing.

Part of the point of unit testing is that you keep the 'unit' under test to be
as small as possible so you don't have these sorts of problems and can run
tests as frequently as is useful. It doesn't remove the need for other types
of testing suites, but they can be isolated and run at separate times.

~~~
lstamour
I think the real point is that "testing in production," more commonly known as
"monitoring," has to happen anyway. So early on, if you have a choice between
adding better, more complete monitoring and adding tests, even integration
ones, the monitoring will prove more helpful once you deploy than the tests
were. Don't get me wrong, it sucks having to manually perform integration
tests but when a product resembles a website and is semi-automatically
deployed (e.g. has staging servers with automatic deployment, rapid rollback
deploys or a canary-server deployment model, a few minutes of caching and few
to no expectations that the app operates perfectly as long as it can be fixed
within half a day, well, that's a very different project. In that environment,
the piece of mind monitoring provides (no client errors in production) largely
outweighs having no monitoring, just tests (did I test everything? What about
(obscure government agency) using (outdated version of IE) who is reporting
that bug?). Of course, as code is more complex than a website, or where you
begin to have significant JavaScript, having at minimum tests for success-
paths will help prevent regressions for application-wide changes, e.g. adding
PJAX to a site and missing an onload. It's just harder to justify tests until
you really need them on some assignments.

------
DanielBMarkham
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.

------
fsloth
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.

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

~~~
radicalbyte
They love it:

ING Bank Case Study: Improving time to market from 13 weeks to Less than 1
week with DevOps and Continuous Delivery:

[https://www.youtube.com/watch?v=9jqY_bvI5vk](https://www.youtube.com/watch?v=9jqY_bvI5vk)

~~~
sz4kerto
It seems they're mostly talking about their client-facing stuff (mobile
banking app, etc.). That I can believe. I very much doubt that there isn't a
committee who has to sign off every single release of their core
infrastructure.

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

~~~
civilframe
I see what you did there :-)

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

------
lolok
lol?

