Live data from Hacker News

Untitled topic

news.ycombinator.com

281–290 of 297 posts

Re: undefined

#281

Earlier quoted context omitted.

That's the thing, Scrum basically assumes that all software teams are so dysfunctional that they won't talk to each other unless and until everyone is watching.

Scrum! It teaches bad teams good habits! Nothing in scrum stops you talking to anyone at any time. The stand-up makes sure that you have to say a few words to the whole team and other interested parties, daily. I like to read criticisms of scrum, when they're not straw-man ones.

I didn't mean it as a straw-man criticism, just an observation that scrum is very rigid and prescriptive; it's all about the what and the how instead the why.

I'm a big believer in trying to persuade people to keep feedback loops short, make teams small and cross-functional, and to design/code/test/ship in the smallest increments possible. At this point, calling an approach agile/scrum/xp carries a lot of baggage.

If people don't get the why (e.g. the team isn't small and cross-functional, and people aren't working on tiny increments) it kind of doesn't matter if you get everyone in the room at the same time every day.

Re: undefined

#282

Earlier quoted context omitted.

I saw your comment and laughed, then realized you were serious. If you are working with 500 programmers, they are likely to be mostly mediocre - the good ones would have run away screaming to better jobs. Sure, if you have 500 mediocre programmers, you need to rope them in with systems. If you hire 5-10 great programmers, stand well clear and let them do their job.

I've struggled with how to respond to your comment. You seem to be taking the view that any project that requires more than 5-10 great programmers is inherently flawed. I think this is false. I've worked on very large software systems before, places that had around 1,000 developers spread throughout the organization. While there were a lot of mediocre, and truly some flat out bad developers, I guarantee you that 5-10…

I've placed a ceiling at 5-10 programmers, because most tasks can be broken into modules such that only 5-10 programmers are working on a module, with decent separation between modules.

Beyond ~7 people, someone needs to begin to coordinate, which is the logical introduction of management and process. But again, avoid large teams where possible.

Linux, Windows, Microsoft office - all great examples of a huge number of modules working together. For instance, the programmer writing the font rendering doesn't need to work closely with the video driver developer, they interact through a carefully designed interface.

But if you are in a startup, odds are you are slinging many large libraries and iterating quickly on new code (that often only you consume). In that case, you're better to "Program, Motherfucker"

Re: undefined

#283
post #198
post #43

The fact that I agree with all of this just makes me sadder at how it was presented. Thanks for building a handy straw man for the methodology developers to attack. I flagged this --- it's virtually content free --- but that's a futile gesture given how susceptible HN is to this particular form of social engineering.

It's about yak shaving as applied to process. (Assuming you read between the lines, as edw519 suggested.) Yak shaving means getting deep into a series of tasks that are apparently unrelated to your final goal, but which logically follow from it: http://sethgodin.typepad.com/seths_blog/2005/03/dont_shave_t... When you're shaving a yak, it might be a productive step whose necessity is not apparent until you analyze the…

Yes.

I have seen many projects fail in big companies because management are frightened of programming. The "risk mitigation" is using large teams of people with the right "skillset" who don't need to think very much because they are doing things according to the "industry best practice" using expensive third party software so that the in-house programmers don't have to make hard decisions.

If you work in an environment like that, and you're reading this, you are probably part of the problem because you are keeping the stupidity alive by struggling through the process and letting management get something delivered. Best to step away from the stupidity and let it fail.

Now I'm going to go and do some programming.

Re: undefined

#286

If you are going to buy his book, use the code "SPRINGREAD".

Also, the book licence is very permissive. "This book is Copyright (C) 2010 by Zed A. Shaw. You are free to distribute this book to anyone you want, so long as you do not charge anything for it, and it is not altered. You must give away the book in its entirety, or not at all." As such, if you can't afford to buy yourself a copy with the above coupon code, send me an email at (gregorylyons@gmail.com) and I will send…

You can also just go to:

http://learnpythonthehardway.org/

And download it for free, including checking out all of the .rst files that make the whole book.

Re: undefined

#287
"Hey, Jules, which one of these commits is yours?"

"Mine's the one that says 'Bad Motherfucker' on it."

Re: undefined

#288

It seems like this is basically just a way of the author saying "I can't be bothered to be accountable for my work or work in teams. If you make me test my code or talk about it I will curse at you and quit." I wouldn't want to work with someone who believed in this philosophy.

Yeah, that whole mental ninja trick of saying a programmer who doesn't want to do your bullshit "process" isn't a "team player" has to stop. It's just a manipulative way of calling someone autistic, a nerd, anti-social, and other offensive things that aren't right.

I mean, I don't go running around calling you a cheese eating brown nosing smiling sales douchebag with no real skills other than talking and pressing palms do I? Then don't say I'm an "anti-social nerd", I'm pretty damn good at talking to people.

Re: undefined

#289
post #66

Does Programming, Motherfucker really scale though? Every process listed is about teams of people Programming Together, Motherfucker. I've seen two people engaged in Programming, Motherfucker without Talking to Eachother, Motherfucker and the results were Disastrous, Motherfucker.

Nothing really scales. There is no process that will allow 100 hacks to make a Michelangelo, if you want a Michelangelo you're going to have to fucking hire him. If this bullshit really worked then corporate IT departments would be the envy of every startup out there. If your software is late/buggy/whatever the solution is rarely adding people / process. It's usually removing people / process. Process is what allows…

But the reality is that 99% of the time, companies don't need a chapel roof painted, they just need a quick watercolour to put in reception (abandoning the painting analogy now).

It's a business decision - is it cheaper to hire one genius to produce something amazing or to hire a few mediocre programmers and manage the heck out of them to produce something that just about works?

Post reply on HN