Live data from Hacker News

Coconut Headphones: Why Agile Has Failed

mikehadlow.blogspot.co.uk

131–133 of 133 posts

Re: Coconut Headphones: Why Agile Has Failed

#131
post #128

Earlier quoted context omitted.

It was your fault. You made a modification to a production database without understanding the full repercussions. You brag about how your refactoring made her software better, but you are ignoring the fact that you got into that mess because of a failure to follow best practices and common sense.

Sure it was my fault she used functions within functions because she didn't know how to understand Pythons module system. It was my fault she had big nested hashes without any comments to explain the structure. It was my fault she had two variables "Indexes" and "indexes" in the same function. I must be the shitty coder, not her.... I at least try and make my code maintainable.

She may be a shitty coder [1]. But her code worked at the time she wrote it, right? And it only broke after you went in and fiddled with the database without first checking to see what systems and programs were using that database and how your changes would affect those systems and programs, right?

[1]Or she may not be. Often times when you develop a system or even write a piece of code, you operate under certain constraints that might make it impossible to make it fool-proof. You may also not have the opportunity to come back and refactor it later. Maybe that was the case when she wrote her code. You may have had the time to debug what she wrote and even re-write it from scratch. She may not have had that luxury.

Heck, maybe she wasn't even a professional programmer. Maybe she had just taught herself some basic programming and wanted to apply it to the job to add value to the company and succeeded in doing so, and she had no idea that some douchebag would come in at a later date, break her program and then blame her for being a shitty programmer. The point is: her code worked at the time she wrote it. It was you who broke it. End of story.

Re: Coconut Headphones: Why Agile Has Failed

#132

Earlier quoted context omitted.

I've read your comments a couple of times and still can't really see what you've added. You're talking about very abnormal situations. Companies that are so technically incompetent they have to hire you. And then saying that we should listen because in your abnormal experience of dealing with teams so dysfunctional they can't even ship bad software that agile at least gets them going a little bit. I suspect almost an…

The thing is that following situation is really common: Company has an average team, maybe even bit worse + 1 good person. The managers are not that great either. Everything is average. The team has been doing something, nobody really knows what, nobody really knows at what pace. Nobody knows what they should be doing. Occasionally the company releases something which sells a bit and customers give some feedback. Mos…

> Company has an average team, maybe even bit worse + 1 good person. The managers are not that great either. Everything is average.

I think the application of the OP here is "fire the bad/mediocre managers, put that 1 good tech person in charge". Couldn't they do that?

Re: Coconut Headphones: Why Agile Has Failed

#133

Earlier quoted context omitted.

I second this. My team is about 18 months into our transition to agile, and it is a tough road. This book has been an excellent resource. The one gap is that it mostly focuses on greenfield projects. It does a good job of highlighting the parts where legacy systems will make agile more difficult, and I understand that spending more time on that would have made the book harder to understand. But we've had to do a lot…

I'll repeat bcobb's recommendation for Working Effectively with Legacy Code . It's the bible. In my Let's Code JavaScript screencast, I've recently started a three-part special on legacy JavaScript code. It follows my efforts to "do it live" with actual legacy code someone else wrote. You might find it useful. (Full disclosure: subscription required, and parts II and III don't come out until April 4th and May 2nd.) h…

Thanks for the detailed reply! I understood your intent, don't worry about the tone.

We're a small enough team that we all understand the business drivers. The main goal of our agile transition is to improve predictability and clarity. Month-wide error bars on a three-month release don't help those goals much.

Right now we're working to shorten our release cycle and learn how to communicate clearly even when it hurts, on the assumption that shining light on the difficulties will help us find and solve the problems as quickly as possible. But it's definitely a painful transition.

One more point: I agree that negotiating scope with a fixed schedule is difficult. We have done that occasionally. But sales and business people are definitely more willing to accept schedule slippage than scope reduction.

Post reply on HN