Actions from Adrian HowardMovable Type Pro 4.382013-04-23T10:38:26Zhttp://blogs.perl.org/mt/mt-cp.fcgi?__mode=feed&_type=actions&blog_id=0&id=183Commented on How to be agile without testing in Ovidtag:blogs.perl.org,2013:/users/ovid//11.4556#6404972013-04-23T09:38:26ZAdrian Howard
So I don't dispute what you say about tests, but I will cheerfully dispute whether or not currently recommended best practices in testing are the elusive Holy Grail of performant software.

Hmmm.. whose best practices are you reading ;-)

I've been running workshops on the advantages of a more experimental metric-driven approach for a couple of years now. Jez Humble's CD book was published nearly three years ago. The classic "The Deployment Production Line" paper from Agile 2006 is more than six years old now.

We've got the Lean Startup folk ranting about CD, metrics, split testing, etc. for the last three years.

Maybe it's just that I spend more time with new product development and startups - but this sort of stuff is best practice now.

It's just orthogonal to testing.

]]>
Commented on When Must You Test Your Code? in Ovidtag:blogs.perl.org,2013:/users/ovid//11.4594#6271582013-04-22T13:12:08ZAdrian Howard
A few random musings.

First, alluding back to my comment-that-never-made-it-through-MT-sucky-sign-in - a large chunk of your approach to when to write tests is based on the assumption that most tests are written to detect error (or harm - in your elegant repositioning of priorities).

There are other reasons to write tests. To drive the design (you know I'm a huge TDD fan). To mark a goal for completion (a bunch of the BDD / acceptance test driven school). I'm sure they are more.

Personally I tend to write lots of design-driving tests, and very few harm detection tests.

That's not because I don't value preventing harm - it's because my purpose in writing tests is to drive the design. That's going to produce "waste" if you look at the test suite as protecting from harm. However, for me anyway, it produces less waste than the inevitable debugging sessions that result when I don't write in a TDD style.

I am a massive, massive fan of continual deployment/delivery - but in phrasing it as an alternative to testing I think you're doing both CD and testing a disservice.

They are servicing very different needs, and the advantages that CD give you are often interestingly different ones from the advantages that testing give you.

Tests (for me) are, mostly, about the health of the code.

The metric / experimental culture that a CD approach produces is, mostly, about the health of the business.

Adding CD to the mix hasn't really altered my approach to testing at all. Because most of the tests that I write are not about harm or business health. This is the pattern I've seen in other organisations too.

It has, however, completely changed the way I attack defining and discovering features, managing deployment, etc. Story writing has changed. The idea of "delivery" and "success" and "done" have all changed.

Testing - not so much.

You also - of course - have to be working in an environment where CD works to the fullest effect. Doing this stuff in, for example, the mobile app space is considerably more challenging.

]]>
Commented on How to be agile without testing in Ovidtag:blogs.perl.org,2013:/users/ovid//11.4556#6268682013-04-22T12:48:37ZAdrian Howard
I do so love the continual delivery stuff. It makes building a
culture of experimentation so much easier.

That said - you seem to be assuming that the only reason to write
tests is to find bugs / behaviour that the customer doesn't want.
There are other reasons to write tests.

For example:

I write the vast majority of my code using TDD. Here I'm writing
tests to help my design.

]]>
Commented on When Must You Test Your Code? in Ovidtag:blogs.perl.org,2013:/users/ovid//11.4594#6268542013-04-22T12:47:25ZAdrian Howard
can i comment?
]]>
Commented on Random thoughts about agile software development in Ovidtag:blogs.perl.org,2013:/users/ovid//11.4505#4882582013-04-07T09:27:27ZAdrian Howard
Heh. I actually think the "no process" folk are the least of your worries.

Generally the people who have the biggest problems are the folk who think they are agile - but aren't really. They've sent a project manager on a CSM course and they've come back - added a couple of Scrum practices (usually leaving out the really important ones like the process-changing retrospectives) and think that's job done. Suddenly all the project managers are renamed "scrum masters" and the company is "agile".

Not.

As you say - it's the philosophy and organisational change stuff that's hard.

Also - I do think you do have to be careful with the "adopt your process to fit your needs" approach. Because a weak reading of that produces the bad systems I just talked about. People adopt the "easy" stuff that fits in with their current way of working, and avoid the "hard" stuff that requires serious changes in their working context (no matter how much that context is the thing that's really f**king them up).

Yes all agile processes are designed to be optimised and changed over times... but those changes are aligned with the underlying agile values and principles.

The "modified agile" phrase raises my hackles too - because it usually means it's been modified into waterfall, or whatever their old process was, and it's not actually providing them with any useful value.

]]>
Commented on Counter-productive over time in Sawyer Xtag:blogs.perl.org,2012:/users/sawyer_x//87.3953#2197252012-10-15T11:31:22ZAdrian Howard
I'm firmly in the pro-dependency camp for the work that I do, but I think that you're a little unfair to the folk that go the no-dependency route. There are definitely those who know how to manage dependencies - but choose not to because of various sensible reasons.

For example the 'Those situations are no longer a problem' line isn't true in my experience. There are many places that have large chunks of infrastructure tied to certain versions of perl and certain chunks of dependencies. Inserting new stuff or integrating new stuff into those environments is non-trivial. Yes we have great tools now for helping avoid those problems - but if you already have ten years of legacy code then shifting everything over to a new style is non-trivial. In those situations dependency-free set ups can be a godsend.