Monday, December 10, 2012

Beware the Agile Smells

For a while now I've been somewhat disturbed by all the methodologies I've so eagerly studied during the last few years. You know, the Agile movement and the Craftsmanship movement that's been coming on strongly. I've been troubled by all the time that is consumed with other activities than coding in my projects.

When I first saw the Programming Motherf**ker manifesto I thought it was ridiculous, but I'm not all that inveighs now. Even though I'd still call it silly it has some kind of point, because lately I've consciously been moving away from safety and coming closer to performing. I'm backing a couple of steps toward where I once was, the pragmatic programmer moving quickly just doing stuff. That was before I was infected by Agile.

Slowing down

Doing agile is a lot about safety where you time box stuff in short iterations with up front estimates, which is good in many ways. But when you spend too much time preparing, planning and estimating it stabs you in the back in the end. Your velocity would be better if you just did something, instead of four of us playing planning poker about if this is a one or two point story, and how you'd best divide it in tasks. I've also had problems with endless retrospective meetings and ad hoc discussions about how we work.

Also TDD and Unit Testing can have the same problem; it can easily be overdone. It's great in so many ways, but you need to keep a good balance between safety and productivity. I'm a big fan of Unit Testing, don't get me wrong, it's just that I don't think you need to test everything. Nor do I think you need to inject every single dependency. More on that later.

Speeding up

I came to notice a course by Dan North called Faster Software Delivery, held in Norway, which sounded really interesting to me. It seems to address exactly this! But since I live in Sweden I asked him on Twitter if there was any book or screencast on the subject, but unfortunately no. A book is in the writing though! However he pointed me to a talk he's been doing on a couple of conferences called Patterns of Effective Delivery. I found a good webcast of it here. You really should watch it when you're done reading this post!

Facebook Poster
Another interesting talk I've found lately is this 10 minute speech from JavaZone by Christin Gorman. She complains about the way of coding taught by Uncle Bob where everything should be broken down in methods of ideally one line of code, and naming that method properly so it's obvious what it does, to make the code more readable. I'm not quite sure who's side I'm on, but I find the discussion really interesting, and the best way is probably somewhere between the extremes.

At Facebook they have a culture inherited from Mark Zuckerberg encouraging to do stuff fast. Mark has this saying, "Move fast and break things", claiming that if things don't break you're not moving fast enough. Just shortly ago we often saw that in production, but now it seems they've either slowed down or put a wall of testers between the fast moving programmers and the production environment as I haven't had much problems with Facebook lately. They also have it written on their walls that "Done is better than perfect" to remind themselves to always keep shipping... that's something I really can relate too and actually put up that poster on a wall next to my desk!

Agile Smells

Talking too much

Since I started doing Agile I've had a lot of more meetings than before. Meeting are good though, making sure we're doing the right thing and keeping every stakeholder up to date with the outcome. But since we have them frequently it's important to keep them short and to have them when needed.

Changing too much

Being open to change is a cornerstone in Agile, and we should be – both in what we do and how we do it. But if we’re too open to change it becomes a problem. It may be adopting a new hot technique without the need for it, merely because there’s a lot of fuzz around it. It may also be not giving the ideas from the previous retrospective a fair chance before changing again or changing back to normal as we can’t manage the work to apply the decided change.

Continuity is needed for any methodology to work, so we can’t expect something to solve the problem in the first week. If something is obviously bad you should of course drop that practice directly but make sure you give your ideas a fair chance before ditching them and trying the next.

Prototyping too much

Prototyping is generally a good practice, where we invest as little as possible to gain as much knowledge as possible. We need to make sure though that we don't invest too much in the prototype though, as it would take away the benefit. Prototypes should be quick to make and shown to the stakeholders as soon as possible, and once the general idea is decided it should be terminated. Optimal efficiency is reached when the prototype is hand drawn with the client present and participating.

In some cases it may also be advisable to use tracer bullets instead of prototypes, a technique from the book The Pragmatic Programmer. Instead of creating a prototype you start writing the code with a first decent idea of how it should be and forge it to perfection through continuous feedback as you go.

Estimating too much

Estimates come to a price, and that price is that it takes time. Hence, by estimating, it will by definition take more time to do something. The more time you put into the estimate the more time will be added to completing the task. Here you need to find the balance between certainty and effectiveness. How much is the estimate worth? And we all know that estimates, however much time was spent making them, are estimates and not promises.

Testing too much

Uncle Bob says he demands 100 % code coverage. What a terrible waste of time for most projects! If you do pacemakers or deal with nuclear devices, fine, but if you do a corporate web site? Hell no! Test logic, test states, but don't test that the text you enter in the CMS show up on the web page - you'd notice if it didn't - and no one would be harmed if it failed to!

Unit tests are great in so many ways, but you need to keep a good balance between safety and productivity. I'm a big fan of Unit Testing, don't get me wrong, it's just that I don't think you need to test everything. For example obvious things. Or tons of nuances. Find all paths through the code and make sure a test case cover them. Would ever a bug occur, add a test for it and learn from it what kind of test you were missing. Certainly a useful one.

Kent's tweet
Nor do I think you need to inject every single dependency. If you're in the top layer of the code, which will only be used in this specific project, it can be OK to call that static method in the core formatting library without making a wrapper that implements an interface that you can inject. And you do not need to inject a wrapper of the CultureInfo class to make sure that your test will still work if you'd suddenly would change culture (unless you have a geographically spread project of course).

Kent Beck sent out an excellent tweet a while ago; "First you learn the value of abstraction, then you learn the cost of abstraction, then you're ready to engineer". In the first 10 minutes it was retweeted by 91 and favorite by 24!


Agile is good in many ways, but agile doesn’t necessarily make you go faster. As a matter of fact it may very well slow you down if you’re not careful! By paying close attention to what you do and what value you get from it you will be able to be more efficient by being less agile. Or rather, being the right kind of agile. The right level is no fixed though, so I can't tell you that. I just urge you to be observant and find the right level for you.


Per Lundholm said...

Check out JFokus 7/2 for Dan North's tutorial "Accelerated Agile".

Unknown said...

Although I failed to get it across properly in my 10 minute talk at JavaZone, balance is all I'm really advocating too. not ONLY < 6 line methods. Use the size or abstraction level that works best AFTER tidyng up the code. I fully agree with you about unit testing too. I love unit testing, but 100% has a too high cost / benefit ratio. Holy crap, I just sounded like a manager. Sorry bout that.
When it comes to agile practices, my main tip is to understand why they are there, so you'll notice when they fail at delivering. If they fail, either fix it or drop it.

Unknown said...

Hi. Based on this post alone I'am afraid that you are missrepresenting the whole point of agile as concept and also TDD as a way to design code. Both encourage own responsibility and accountability as well as a push to consider and constantly check what and why you are doing the things you are doing.

TDD is not all about 100% code coverage, it is very much about the initiation of the thinking process when designing code. Working with a large mass of code where many developers are involved and changing eachothers code is much easier when you have an ability to get a fast feedback when even a small and trivial functionality gets broken. Good auto tests are all about shortening the cycle of change and verification of the same and how that change affects the rest of the code. Manually testing even trivial functionality takes time and the bigger the app the longer the turn around time.

Finally, a methodology and or process will never give you a great product nor world class quality. Responsible individuals who can adopt their practises as seen fit according to their own prerequisites, maturity and situation will.



Tommy said...

Per: Yes, I've seen that. I really wish I could attend, but it unfortunatley seems that I won't. :-(

Christin: I'd say I'm on your side then. ;-)

Rijad: I agree about TDD being a good way to design code, and with the benefit of a bunch of unit tests as a safety harness. As I said in the post, I love Unit Testing. I definitely don't want anyone to stop doing TDD. But there are times you can go faster without losing much by not being all that strict. See this excellent answer to a Stack Overflow question but noone less than Kent Beck for example.

About methodology I don't really get your point. It seems you're trying to say I'm wrong by claiming the same thing I just wrote? Adapt the process to your need and beware of the smells? Please read my previous post for more on that subject.

Max said...

It's not all about agile or methodology in general, some things is rooted in how we work in the modern office.

I agree with this guy: great work needs focus time and a quiet environment - which is why most creative people have a hard time working at the office:

Unknown said...

Hmm, the downsides you are describen doesnt sound like "aglie" to me, rather the way you work? :)
If you did not have sprints for instance, and were working in the same fashion you would most likely never be able to concentrate on actually programming stuff since product managers would interupt you all the time with "more important things to do".
And if you are not agile, and adapt to change, between sprints (which by the way does not mean "adapting all new hot stuff that comes along" - but of course that depends on the customer/procudt owner), then once you deliver it will not be what the customer wants, and in the end will take three time as long to do what he wanted and cost three times as much (which may of course be fine on a programmers level, although myself I like to start with something new rather than redo stuff).
And the daily stand-ups - well yes that Is a meeting, and a daily ont ath that. But for a team of 3-8 persons this should only take 5-10 minutes, and the Scrum master should make sure to schedule it when it hurts the least (before lunch maybe if you have a fixed lunch time?).

Estimations is also very tough on programmers - but IF they are a requirement the agile way,m is in my mind anyway, better than wasting even more effort into very detailed and low risk estimates where you basically need an design for each item before you can say with any confidence how long it will take, and after this you'll still have to wait 6-12months before actually doing it, and then the estimate is useless, and in the end it takse however long it takes anyway - so Point poker is a quick and easy way of not having to do tedious estimatins I think...


Tommy said...

Max: The guy has a point, but I don't agree with his solution. Having silent thursdays when noone can talk to each other? I have a hard time thinking out anything less agile than that! He has a point though, and we should all think about not disturbing our teammates if not nesseccary. Using asynchronus channels for non-urgent matter for example.

Unknown: I think more than people in my surroundings have these problems, hence the post! I'm not against Agile in any way, quite the opposite! I would never go back to working non-agile again! So do not think of this post as being agile-bashing, rather think of it as a post where people who have difficulties in their agile transistion can find help.