Hacker News Reader

Comment by itsnotme | Hacker News Reader

> [Obligatory plug and disclaimer: Agile professional

You sell process for a living. You claim, "After all, it's not like you can have no process at all. Whatever you're doing already is a process." When you said that, you accidentally got something right.

Programming is a process. It's the only one that fucking matters if you're a shop that sells software. All the other process comes from snake oil salesmen as yourself, or pointy haired bosses who don't know a fucking thing about programming.

Programming. Either learn and do it, or get the fuck out of its way.

View on HN

Spoken like a true cowboy programmer who can't collaborate his way out of a wet paper bag and blames process when a team he's part of fails because of that...

Funny thing is, both this guy and the author of the TFA touch the same problem in passing: regardless of the process, there are too many incompetent people plaguing our industry. Instead of addressing the problem, managers usually exacerbate it by trying to "fix it" with a "correct process".

No process in the universe is going to turn the Infinite Monkey Theorem [1] into solid reality.

[1] http://en.wikipedia.org/wiki/Infinite_monkeys

Yet it never occurs to them when dividing people into groups that maybe they're the incompetent ones...

Who's more competent? The person using Agile successfully and getting things done, the guy using no specific development process and getting things done, or the guy writing long blog posts about why he doesn't care for a development process he doesn't understand and doesn't need to participate in if he doesn't enjoy it?

I'm currently on two missions. In one of these, we kick ass. Deliver on schedule or even in advance. It's scrum, we simply work as a team of four and ship, ship, ship, ship, feature after feature and fix after fix. We have our hands free, management is trusting our cell with the strategic future of their Tech tree, and we deliver.

In the other mission, I am not making this up, I spend 1hour/day on poor excuses of stand up meetings, 3 hours/day in various meetings, 1hour/day on various administrative tasks and 3 hours/day preparing powerpoint plannings for the meetings of the next day, and I'm a dev. I work with equally awesome devs in either mission, but in this one the customer is absolutely crazy inefficient and a control freak, and the best example of what NOT to do with scrum I've ever seen.

So who is more competent? The me that's killing it with scrum in the first mission or the me that can't do anything because of scrum in the second mission?

The first you. The second you needs to run far away from what he's doing. :)

I was in that situation before -- bad agile is BAD. I was on a team of 4 developers with literally 8 project managers. I know how that daily 1 hour crappy stand up goes. I also know how it feels to have deliverables for half the project managers in any given week, and what it's like to get constantly interrupted by 8 different people during your minimal development time to answer non-urgent questions.

But you know what? Not everywhere is like that and you usually have a choice to find something else. You're obviously competent enough to find something else; you already have two things going on.

If they aren't doing it right and they aren't listening and you aren't happy, GTFO.

I enjoy programming with other programmers. But I don't collaborate well with people who don't know a fucking thing about programming who try to put process on top of the process of programming.

Cowboy is a complement. It doesn't mean "lone ranger" or "asshole", it means lazy, hard worker who takes the shortest path to greatest output. So, yup. Cowboy here.

I don't collaborate well with people who don't know a fucking thing about programming who try to put process on top of the process of programming.

Fair enough. But what about someone who does know a lot about programming, who runs his team using agile methods. Could you collaborate well with that person?

HN's algorighm thinks I'm a spammer and wouldn't let me reply, but really, itsnotme.

I could collaborate well with that person. If I like the product and the people enough I'll work on a team that uses "Agile". But I do it knowing that process is not communication, and that standups are a fucking joke.

No but communication is part of any effective process. Standup is just having everyone say what they accomplished yesterday and what they're planning on doing today. If you're on a team with more than three or four people, it's a useful way to get a quick summary of where everyone's at. Some people are good at letting other people know when they're stuck, but some aren't, and if you've got the latter on your team standup is a good catchall. Most teams, whether they're in software, sales, or sports, have some variation of the standup. Of all the scrum paractices it seems like it should be the least controversial.

No amount of process can fix bad communication. Standups are an attempt at that. Teams that have good communication succeed more, and standups aren't integral to their success. Teams with bad communication fail more, and standups can't help them.

Sales teams and sports teams don't work as a comparison, they aren't building something (sales is a particularly bad example, most sales team members are in direct competition with each other). I'm trying to imagine standups on a building site.

Tom: "Yesterday I.."

Everyone cuts Tom off and talks over each other: "No shit, Tom. You're gonna work today, too." "That insulation isn't going to unroll itself!" "Tell us, dear Tom, will you be screwing the sheetrock in with a DeWalt or a Hitachi?"

Good teams communicate while they build, and know where each other are.

No amount of process can fix bad communication.

Sure it can. If I've got a team member who can't be bothered to let people know what he's doing on his own, I can hold a standup every morning to make sure the information gets communicated to the team. If he lies every day about what he does, the longest he can go is one sprint before his work gets verified.

I'm trying to imagine standups on a building site.

I don't know, I think it goes something like this:

"Hey Tom, how far did you guys get on the roofing yesterday?"

"Only about a quarter of the way. Some dipshit ordered the wrong shingles."

"Ok, Bob will you get on that today so Tom and Dick can finish the roofing? How about you Fred, where are you at on the sheetrock?"

"Living room and kitchen are done, I should finish the bedrooms today..."

etc. Pretty much what actually happens at a construction site if the builder is competent.

I don't know what kind of standups you've been in but they sound like they were run by someone with no training or experience in the process.

Good teams communicate while they build, and know where each other are.

How do they communicate? What if Tom doesn't know what Dick's doing and Dick doesn't think to tell him because he doesn't know Tom needs to know? This doesn't magically happen even if everyone is individually a star at what they do.

"Sure it can... If he lies every day about what he does, the longest he can go is one sprint before his work gets verified."

That's not fixing bad communication. That's wrapping it up in process, and calling it "good enough". The team communication, and probably its morale and output, still sucks.

"etc. Pretty much what actually happens at a construction site"

That communication happens continuously, throughout the day. If isn't happening continuously, throwing a standup at it ain't gonna fix it.

That's wrapping it up in process, and calling it "good enough".

"Good enough" is certainly better than "not good enough". And it doesn't have anything to do with morale. The team's morale might be sky-high and they can still make mistakes because person A didn't know what person B was doing in a timely fashion. People have a tendency to overestimate their skills in general, and communication is no exception. Standups are just a form of insurance and cost almost nothing. Even if your team communicates like they're telepathic, 15 minutes a day in standup isn't going to hurt them.

If isn't happening continuously, throwing a standup at it ain't gonna fix it.

If I'm managing 5 job sites, I'm not there continuously. It might not be perfect, but once a day sure beats nothing. Most of the time when someone is doing something wrong, they don't know they're doing something wrong. No one is going to call me up and say, "Hey, I'm about to do something stupid and wanted to run it by you."

"Good enough" is certainly better than "not good enough".

In the scenario that you described, someone went from not communicating at all to lying every day, and getting "caught" at the end of a sprint. Standups didn't fix anything there. Also, there is a world of difference between calling something good enough, and it being good enough.

If I'm managing 5 job sites ... once a day sure beats nothing

If, as a manager of 5 teams, you feel like you need a direct, daily report of what every person on every team does, your life is going to be hard. If you attempt to control those teams by adding more process, you will interfere with the productivity of your good teams, and your bad teams will continue to suck.

The scenario isn't about the lying, I was just anticipating the argument that the standup wouldn't improve communication if someone wanted to subvert it. The basic situation---a teammate who isn't communicative---can only be 'fixed' by getting him to communicate. You might argue that I fire him and spend weeks looking for someone who codes as well, or alternatively hire a 'communication coach' to help him with his personal problem (I'm not sure what solutions you're offering) but I prefer the vastly simpler option of just having a standup. Which also solves the problem of good communicators who don't realize they've got something worthwhile to communicate.

We don't do standups to fix broken team communication. We do standups to augment ordinary team communication. If you've got an uncommunicative team member, that's not unusual. If you don't have an uncommunicative team member, now that's unusual.

If, as a manager of 5 teams, you feel like you need a direct, daily report of what every person on every team does, your life is going to be hard.

I may or may not need the report, but I want to make sure that every member of every team knows what's going on on their team. That's not adding process for process' sake, it's just ensuring communication rather than leaving it to chance or some utopian vision of human nature. A 15-minute standup isn't going to hurt a good team's productivity, while it could greatly improve the productivity of a mediocre team.

A 15-minute standup isn't going to hurt a good team's productivity, while it could greatly improve the productivity of a mediocre team.

It takes a lot to noticeably hurt a good team's productivity. But it's mean, just fucking mean, to punish a good, productive, communicative team with more process because you also manage crappy teams.

[I]t's mean, just fucking mean, to punish a good, productive, communicative team...

I didn't say standups don't benefit good teams; quite the opposite. You've missed (or ignored) my point that even good communicators miss conveying important information sometimes. And if the team is really so naturally communicative, they're hardly going to view a standup as punishment. Again, I have to really wonder what kind of standups you've been subjected to that would trigger your revulsion. It's like being violently opposed to eating with a fork. Technically, no, you don't need one but it often helps. Either way, it's nothing to get worked up over.

Either way, it's nothing to get worked up over.

Oh, I agree. My language was for emphasis, not representative of an emotional state. It's interesting to talk to someone who thinks that the same process can save a bad team and make a good team better. That though had certainly never occurred to me.

> A 15-minute standup isn't going to hurt a good team's productivity

It can send a powerful message that the team is not responsible for producing the software.

It can send a powerful message that the team is not responsible for producing the software.

Could you elaborate? I have a hard time imagining how spending a few minutes describing your progress and your immediate plans could possibly give you the feeling that you're no longer responsible for what you're working on. It seems to me that not ever being asked about what you're doing would powerfully convey that message.

Daily stand ups would be stupid in my current project.

Professionals should have a broad responsibility for the end result and appropriate freedom over the approach taken.

Externally imposed process creates a situation where professions are responsible for executing that process.

People ask dumb questions like "Is this Agile?". Who cares? The correct question is "Is this what makes sense to get the right outcome?"

My personal experience is daily stand ups are used as a tool to mandate a start time. This time was been inconvenient for staff with young children to drop at school. I remember hearing the sigh or relief from a person when they were dropped.

Personally, I like having a daily stand-up. So do my colleagues. First thing in the morning is a great time to sync up on things.

I have seen places that do them poorly, and I gather that's what you've experienced. But it's also possible to do them well.

Well, if you mean "Programming is a process" to include techniques of effective collaboration, then agile is part of programming.

Claiming that people who try to define methods to do that better "don't know a fucking thing about programming" is A) a non-sequitur and B) indicates that you don't collaborate well, period.

No, Cowboy is not a compliment. It means a hard worker who takes the shortest path to the greatest output of code that doesn't fulfill requirements and which nobody else can maintain.

You say "techniques of effective collaboration", I say "talking to people". If you need guidelines for that, that's cool.

The thing that suggests to me that you and I wouldn't work well together is that you make broad value judgements based on twisted interpretation and extrapolation of these comment threads.

And you don't?

I hate that term cowboy programmer. Very effective rhetoric, though. Let's take the archetypical example of people who get stuff done without our process, and call them cowboys! Now, anytime someone points out a dumbass process-driven decision that could have been avoided by using our brains, we can just disparage them as a cowboy.

Note, we're using small-a agile at my shop and it's working well, but that's because of good people, not because of blind adherence to a process and eschewing individual thought.

It's ridiculously easy to get stuff done without any process when you work on your own and the projects are small enough for that. You don't even need to be very good to succeed in such a scenario.

Cowboy programmers are those who extrapolate from that and believe that teams efforts can work the same way, and who think that process causes only inefficiencies rather than preventing much larger ones.

But for a team to work effectively, you need structure, you need process. Even if the team members are very good, they can get completely lost without process. If they are not completely antisocial, they will come up with some sort of process themselves, but it's not automatically going to be a very effective one (and that has nothing to do with their programming skills). The point of agile is to try and minimize process while still enabling teams to work effectively. And it has absolutely nothing to do with "eschewing individual thought". Quite exactly the opposite, really. But of course there's no concept that can can't be perverted into its opposite by a sufficiently point-haired idiot.

Yeah man, I get that. I said that I'm at a small-a agile shop and it's working well for us.

That doesn't change the fact that the only time I've seen the phrase 'cowboy programmer' used, it's as a preemptively ad hominem argument that anything besides Capital A Agile As Written On Stone Tablets can't possibly work. And if it does, it's cause they're cowboys.

As a counterpoint, demanding something is deployed every 2 weeks, whether it's a 1-week task or a 3-week task, leads to plenty of cowboyism right within the process.

Who demands 3 week tasks launch in 2 weeks? And Agile dev cycles delivers whatever is ready every two weeks, instead of shipping everything on an arbitrary deadline.

Interesting. So how do you build things that take thousands of programming hours to complete? What about projects involving complex rulesets requiring legal input and/or HR input?

Programming is a means to an end. The end is solving some problem. For many problems programming is a small part of the overall solution.

If you're planning a project to take thousands of programming hours to complete, you are an idiot, and nothing can help you.

So, there's nothing worth building that can't be accomplished in under 1000 hours?

Lots of meaningful things take thousands of programmer hours. Projects where those thousands of hours are meticulously planned for by non-programmers (whether by using "Agile" or any other process that sits on top of the process of programming) are fucking doomed from the jump.

The software that keeps all modern airliners in the sky is written by companies that have lots and lots of process. Do you think those software projects are doomed from the jump just because there's a lot of process involved?

The cost/benefit tradeoff is very different for those companies. Usually, no one almost dies when your social app goes belly-up.

Sure, I was just trying to prove a point - more process doesn't necessarily mean worse software.

That's right. It means slower software.

That's not what Agile consultants are selling.

You said "...Agile, or any other process...", so you're explicitly not limiting your statement to Agile methodologies.

Do you think _slower_ (as in taking longer to develop) software is the only outcome of the processes that avionics software companies use? Or do you think they are wrong or would be better off not using any of these processes?

The companies have a lot of process, but how do you know how the software was written? Usually I see things like a huge project that is failing while the initial prototype that works gets upgraded to production...which has often been produced by cowboys.

However, I don't work in the airline industry. I do work somewhere where one errant line of code can destroy productivity around the entire globe, brick computers, and really piss people off, and it's low process, cause the process guys can't ever get anything shipping.

As for Agile, I would suggest reading the Mythical Man Month circa 1995, the final chapter covers iterative development and makes a lot of sense, imho. Not sure why we need people with certificates selling snake oil where common sense works just fine.

I don't know that Boeing follows your cowboy methodology. Hipmunk probably does. But Boeing puts the planes in the air.

Processes implemented to save lives are the product of death, and the process is put there to slow things down. Ask your friendly agile consultant how much their process is going to slow down your company.

They will tell you that Agile will make you faster. They might even be right, if it's replacing a bigger, worse process that already exists on top of the process of software development. But if it's adding a layer, it's going to slow you down and get in your way.

That's not obviously true to me.

Any professional has some process, explicit or implicit: it's the observable regularities in the way they work.

Any team is going to have some explicit process, because there's no way people will converge on the maximally effective way of working together without some discussion.

So as far as I can tell, what you're saying is that it's impossible to take any process ideas from an external source, because every team is already maximally efficient. That doesn't make much sense to me.

In our case, the process we've converged on is the most efficient one we can find. But we're always looking for ways to make it more efficient.

So as far as I can tell, what you're saying is that it's impossible to take any process ideas from an external source, because every team is already maximally efficient.

Nope. I'm saying that the process of programming is what we should focus on getting better at. We should take improvements from wherever we can find them. Getting better at the process of Agile or Waterfall or Scrum or XP or Kanban or whatever else is dreamed up is tangential to our progress as programmers.

I agree that nobody should focus solely on getting better at, say, Agile. I also agree we should work hard at getting better at programming.

However, I don't think that focusing on programming alone is sufficient. A lot of projects fail for reasons other than bad coding, and almost no project exists where programming is the end purpose. You can do all kinds of great programming, but if you make the wrong thing, you're screwed. Ditto if you have a bunch of individuals doing great programming that doesn't add up to a functioning project.

I also think you're creating a bit of a false dichotomy. When I first tried XP, it wasn't for the sake of doing XP. It was because I wanted to improve how we made things for our users. So exploring XP wasn't tangential to better programming; for me it was closely related, in that programming was a big part of making.

... if you have a bunch of individuals doing great programming that doesn't add up to a functioning project.

That's impossible.

A) It's kind of irritating for you to ignore everything except the one thing you'd like to argue with.

B) Unless you have some mathematical proof of what I'm unaware, I believe you mean, "I don't understand how that could be the case."

Well, the Agile approach is to break them down into smaller things that can be accomplished in under 1,000 hours.

"There's nothing that can be accomplished in a single chunk taking more than a 1,000 hours that will produce a system with a manageable and maintainable level of complexity unless it is broken into smaller, well-defined and loosely-coupled components," perhaps.

I meant to answer your original question, but HN decided I couldn't post any more under "itsnotme".

"So how do you build things that take thousands of programming hours to complete?"

By programming for thousands of hours. Through the process of programming, I'd try things out, use what works, dump what doesn't, write tests first where it makes sense, last where that makes sense, not at all where that makes sense, buy hardware where it will save me time and money or work better, interface with it by writing code, step back, look at some mistakes, rip them out, replace them with nothing if I can, or less bad mistakes if I can't replace them with nothing.

You know, programming.

If in addition to my process of programming someone wants me to tolerate some other meddlesome process, well, it depends how meddlesome that process is. If they want me to use a particular IDE, they can fuck right off. If they mandate I write code in a particular order, they can fuck right off.

On the other hand, if they are awesome people with awesome product, I'll engage in standups (or whatever), and I'll write my cards and move them along (or whatever), and burn down my time (or whatever). But I won't pretend that it part of the process of programming, or that it's speeding things up.

Reply on news.ycombinator.com