Hacker News Reader

The biggest determinant of success that I've seen is the skill of the programmers on the team.

No McMethodology can make crappy programmers write good code. Period.

(However, really bad management can make good programmers write crappy code too...)

Exactly!

Factors contributing to the success of a development project, in decreasing order of importance:

1. the skill of the team

2. the determination of the team to succeed

3. appropriate choice of technologies

4. process

In my experience management agendas are much more likely to interfere with 1-4 than to help. There needs to be some kind of hippocratic oath for development managers and process enthusiasts. Everybody pays lip service to Fred Brooks but people somehow seem to keep forgetting his message.

They're forgetting it because they want to forget it.

Businessmen want (for reasons that are somewhat rational) to commoditize everything, including labor. Programming labor has been stubbornly difficult to commoditize. Programmers differ in skill in very deep and complex ways, and can't just be swapped out like assembly line workers.

This is immensely frustrating to the bean counters. Anything that comes along and promises to allow programmers to become commodities is going to catch on like wildfire. The desire is too strong from a management perspective. It doesn't matter how many times such efforts have failed in the past. What's old will become new again.

Exactly. Agile becomes popular because it gives managers wetdream to impose a factory-like process into software development.

Not to mention that it appears to eliminate the long "measuring before you cut" thing at the start of new projects. Fingers on keyboards equals productivity!

I met a ScrumMaster that sees things otherwise.

The point of Agile (and Scrum) is to give responsibility back to the clients/managers: pick one -> time or money, you can't have both; we'll show you why from our user-stories, cards, task-boards, poker-game, scrum planning, etc.

Exactly, this is what "calibration" and "velocity" are about. But the elephant in the corner of the room is that skill still matters, you can't swap a good team for a bad one and get the same velocity. In fact it makes the management problem harder; now you don't just need "a hacker" but a whole team...

Indeed,

Agile theory does make some nods to not commodifying the programmers labor and giving programmers autonomy. But when it's sold the bean counters, they filter for the parts that get them what they want.

We have a lot of decent developers on our team. But management is still stuck in 90's where everything is done as huge framework building waterfall exercise. The word YAGNI doesnt mean anything to anyone here. So yea lot of skilled devs are writing useless frameworks when they could have producing real business value. So I would say the most important thing is the process once you have a decently skilled team.

Yeah that list only holds for successful projects. A broken process can quickly move to the top of the list of reasons for failure.

You left out #0, which is "Knowing what to build." I suppose discovering that is in the realm of #4. Hm.

No, discovering that is market research. I don't see how McMethodologies help there.

That sounds like an assumption that everyone's in the business of selling software. I'm certainly not.

Are you in the business of writing software that never gets used? I have, and I hated it. Quick feedback means quickly finding out if you're building the right thing.

Quick feedback means quickly finding out if you're building the right thing.

I agree. That's why I use a development process that encourages quick feedback. I don't consider that market research because I'm not out looking for customers to give me money in exchange for a DVD full of software. I'm sitting down with the person who hired me and demonstrating what I've done in the past week or two.

"No McMethodology can make crappy programmers write good code. Period."

Can't a McMethodology help crappy programmers become less crappy (and eventually write better code)?

Are there any methodologies that can help with this?

Ideally, poor developers get replaced by better developers, but realistically this (for all sorts of reasons) doesn't always happen. So, if you're a project or team leader, what can you do to elevated the level of code from sub-optimum developers?

Anything? Or maybe it's better to give them "fake" code to write so they stay busy and out of the way.

I don't think so, no. My experience is that mediocre and poor programmers take refuge in high-ceremony work environments like agile, where there is basically an infinite amount of non-productive "work" that can be engaged in, and no-one can criticize because they're following the process.

I do think that poor developers can be taught to be better in a work environment, but it's a painful, slow process, and has to be started with an a keen devotion to the process on the part of the trainee, which if it were going to happen at all, would probably have already happened during college.

I have difficulty imagining an agile process worth following where standups don't reveal that people aren't doing worthwhile things, where retrospectives don't reveal that estimates have gone horribly wrong, and where pair programming doesn't reveal that some people shouldn't be writing software.

What exactly do these high-ceremony agile projects practice?

"Refactoring"

I (the author) agree with you. I also do not like this whole idea of ONE TRUE WAY. From the closing graphs.

Iterative and incremental development isn't for everybody. Lots of teams do things completely ad-hoc. Lots of teams are happy with waterfall. Lots of folks just don't care to change. These are all good reasons why agile might be a bad idea.

My standard for what agile isn't universal, sure. but I'm very happy teaching best practices for iterative and incremental development. You can call that agile, you can call it Joe. Whatever it is, helping people see things and try things they haven't seen or tried before -- and then letting them decide whether it's working for them or not... Over time there can be an us-versus-them attitude that sets up between any two groups of people. We must always be on guard for this. If you're not a servant to the team, you shouldn't be in the room.

Sure, didn't mean to come off as disagreeing with you, as your article makes many of the same points. Just venting because so much of these ideas have become an ideology....I respect that you are advocating a non-ideological approach.

The gaping vulnerability in the traditional ad-hoc waterfall approach is management is constantly interrupting work in progress and changing the priorities, then wondering aloud why nothing ever seems to get done.

Agile is certainly worth the bureaucratic hassles it adds because agile protects developers from the tyranny of ever-changing priorities. At the start of each iteration (every 4 weeks or so) the management team must agree that these issues, and only these issues, will be the entirety of what the team works on for that iteration, no exceptions, no additions, no interruptions. A good management team will respect that agreement and protect the team from interruptions.

This can be solved simply by explaining to your management that Change == Things Will Be Late. If your management can't understand this, then it's unlikely that they'll be able to commit to Agile, anyway.

But using Agile allows you to show this in concrete terms. Waterfall uses the "man hours/months/years" metric which is useless given the difference in productivity between developers. Agile, on the other hand, shows the output that is occurring on average, i.e. what you're realistically going to get.

What I tell people is: what do you want? Do you want to never be told no, but never get what you were promised? Then use waterfall. Do you want to usually get what was promised, but be told you can't have what ever you want? Then use Scrum.

You know what one of the core values of Agile is? People over process.

For fuck sake, the reason the Agile Manifesto came into being in the first place because the people writing it, the people who created various methodologies now known as "Agile", agreed that there was no ONE TRUE WAY, just a set a values they shared. Each and every one of them would agree with you.

This willful misunderstanding of agile is just pathetic. It's like listing to teabaggers going on about death panels.

Back when that is what agile was, I was all for it. But it had become a dogma, just like the dogma that causes you to lie about the tea party and obamacare- you don't carewhat reality is.

Wow, it's pretty surprising to see such a rant get so many upvotes. Your rant is about a bad company (good on you for quitting) but it has nothing to do with Scrum.

You're right that there is for sure no "one true way". For me, I like (the parts I use of) Scrum because (a) it puts a low limit on how long a project can veer off track without anyone noticing (i.e. you can only lose SCRUM_LENGTH time at once, not years) and (b) it puts up a wall that stops business from just coming over interrupting me everything some bright idea pops in their head (they can do this if they wish but it means canceling the current scrum. Usually this is enough to make sure they don't do this for trivial stuff).

Maybe one reason I like it is because I'm the kind of person who always sees "rules" as guidelines, not things to be followed rigorously in all cases.

there is a lot of anger towards the agile movement because it was sold as a tool to pointy haired bosses to impose, rather than a grassroots movement among engineers that embraced flexibility.

the interesting thing is that the agile movement started as exactly the reverse of what you said: as a grassroots movement among engineers that embraced flexibility, not a tool to pointy haired bosses to impose.

If your experience is the opposite, you've been had by someone, and you're blaming agile.

whenever unit tests or test driven development comes up the proponents act like anyone not doing things this way is incompetent. I think the reverse is true

The reverse would be "anyone doing unit tests in incompetent", which is not a defendable statement. What are you trying to say?

Being Agile has become a fad off late. This has led to team adopting agile blindly doing things without understanding the reason or need behind it. This could lead to frustration mentioned by you involving a lot of long ass meetings standing.

I believe as mentioned in the article that Agile is a set of best practices followed by a ever adaptive team. I completely agree there is in no ONE TRUE WAY.

True, It can disorganize the team and make it counterproductive if it isn't in the 'agile' mindset (or hasn't adapted to it in a reasonable period of time).

We implemented it because one of the teams we work with implemented it. The big difference no one cared to notice was that they work in terms of iterative builds of a huge application that they determine the timescales of, and we work on learning products that have prescribed deadlines, sometimes down to "this needs to be done this afternoon for tomorrow morning".

We were still forced to estimate the effort of something that we knew had to be done the same day, and it was to be done by the person who had free time, no the person who it would be the least effort for.

No surprise it was a completely hollow experience.

Thank you, my experience has been same, and I could have not said this better.

I'd like to add that anyone in this position should do exactly what you and I did, and quit. Time is valuable. Leave them to find out the error of their ways by themselves if they're unwilling to listen. They'll think you're wrong. You'll think they're wrong. Fine. Let the free market work it out.

I now work as a contracter elsewhere, solving more worthy and interesting problems, and with wonderful coworkers. Our methodology adapts as required to the problems we are trying to solve. We're incredibly productive and love our jobs, because we think about the product we're trying to create and not about following arbitrary rules in lockstep.

The way to overcome incompetence isn't to fight it but leapfrog it entirely.

whenever unit tests or test driven development comes up the proponents act like anyone not doing things this way is incompetent. I think the reverse is true

Can you elaborate on what you mean by this last part?

Someone who insists on a single silver bullet is probably incompetent.

yes, and the worst part is when the pointy haired bosses become Agile experts and start to look down on software developers. They couldn't write an application even to save their lives but now they feel they are the experts and try to manage the developers.

Exactly. IMHO the role of the Scrum Master only really exists during the daily standup. The rest of the time that guy should be coding with everyone else.

Did you even read the article?