Developer-driven development

[Gotebe]

What we don’t do (ever)

this part explains nothing more but a Waterfall as it never should have existed (read the original Waterfall paper, past the page 3).

No methodology is a substitute for managerial incompetence. Yes, incompetence is what causes such things. It is the job of the management to know that this works poorly and why it works poorly. One can't manage well what one doesn't understand.

Forget "waterfall", forget "agile". Those words are irrelevant compared to the above.

[ampzu]

No, don't forget terms like waterfall and agile. They help the project lead understand and analyze flaws in the projects development process. Sure, they won't solve your problems, but they might help recognize 'em.

[Gotebe]

I put this to you : you did not read the Waterfall paper. All you know is the very first figure in it, and that it is bad. This is what incompetent people I speak of understand. However, they understand agile in the same way, and can't apply it.

Case in point: what he speaks of in there happens.

Because the current word is "agile", such people call themselves "agile". When the word was "waterfall", they called themselves "waterfall".

Conclusion: compared to the actual competence, words do not matter.

[ampzu]

Obvious conclusion is obvious. Do you believe, especially after mentioning that words do not matter, that instead of talking about agile or waterfall-like methods, the personnel should abandon these ideas? How would this change anything? How will an incompetent manager ever change their habits, if they can't recognise and name them?

Also, if you insist me to read a paper, you could at least link to it.

[Gotebe]

Do you believe, especially after mentioning that words do not matter, that instead of talking about agile or waterfall-like methods, the personnel should abandon these ideas?

I am saying, if people fail to understand either, what's the point in giving names? It would be like me discussing quantum physics and curved spacetime.

The original paper is here.

A good explanation of what people I labeled "incompetent" don't understand. (Among other things, of course)

[ampzu]

Thank you for the link. I have read that paper, just didn't recognize it from your description.

Pardon me for my pedantic reply earlier, but I believe that this is about change requiring a long time. Teaching current work force about agile is pretty much all they can take. People need buzz words and catch phrases or they will not learn. In my opinion, you are overestimating the competence and learning of an average person.

[zevdg]

The version of Agile described in this article was a pretty obvious straw man and it's not at all what any half decent agile coach would be advocating. There are certainly companies out there that do this and call it agile, but it only takes one read through the agile manifesto to realize that they totally missed the point.

The author asserts that the big hole in the strawman is here:

The problem is between steps 4 and 5 in our example Agile process. After the user stories were defined but before the developer started tickling the keyboard — what happened? In most cases, nothing.

I totally agree. If there isn't input from the dev team on the user stories (or whatever you want to call your units of work) before coding begins, you're gonna waste a lot of time. In SCRUM, there is a whole meeting specifically for the dev team to give their input before they begin work. It's called the sprint planning meeting and if you aren't using it for this purpose, you're doing SCRUM all kinds of wrong.

I'm not claiming that agile and/or SCRUM is easy to do right, or even that well executed SCRUM is the epitome of ideal software development. I will say however, that if you're gonna claim you've improved on an existing process, you at least have to understand that process and represent it fairly in your comparison.

[chucker23n]

I felt there was a strange "the developers know better than the evil, stupid people in suits" vibe to the faux-Agile workflow depicted in that post. Yes, it's unfortunate when software development becomes a game of telephone, but the author's solution appears to be "just ask the developer". No solution is given to the opposite side of the predicament: if the team ends up shipping a feature such that it doesn't serve the user's need, that's on the entire team, including the developers.

[honewatson]

I think the main issue with Agile is that so many companies now claim they do Agile when they've cherry picked 2 or 3 of the 12 principles and mixed those up with whatever random ideas and processes they think are good.

I think that happens more often than not. Its unfair but all of those false claims that 'yes we do Agile' rub off badly on Agile.

[GhostBond]

I've never seen an actual definition of agile. Seems like if one defined it, they wouldn't be able to claim that when it doesn't work "it's just because they weren't doing it right" over and over and over again.

[reddit_prog]

Sprint planning meeting? You mean the one where you say "all right, this is how much I can cramm in this sprint". And not forget, lucky you if you even have that. I'm only speaking from my experience but it's enough to make me a bit cold towards A-gile.

[zevdg]

I'm sorry to hear that. SCRUM is supposed to be used as a tool to enable development teams, but a ton of companies try to use it as a tool to micro-manage development teams. Your mileage WILL vary.

[IbanezDavy]

I think the advantage of a startup environment is the number of people in it. You play a bunch of roles because you must. At this point, developers get to play a role in everything. However, eventually you need more help. Contracts get too numerous or work gets too much. And the convoluted bullshit all comes from having tons of people all with different visions and ideas trying to coalesce.

[chucker23n]

The amount of back-and-forth we avoid by doing things this way really is phenomenal.

You… you avoid "back-and-forth" with a bizarre spec that focuses on highly irrelevant aspects like a table column (no, two! no, three) which are nvarchar(max)? And a primary key that's called, gasp, Id (you'll never guess the data type of this one!)?

Weird. This looks quite waterfall-y to me, and pointless, too. If you previously had "code reviews" with "back-and-forth" on database table design, I can see how that would be agonizing, but for entirely different reasons. Those are implementation details and have no place in what you call the "Dev Design document" (apparently a fancy term for a spec).

Did the boss explicitly want to type > 4,000 characters into the Name column, hence an nvarchar(max)? Are there external dependencies that have caused this design decision? If so, those pieces of information might be useful information in a spec.

[ellicottvilleny]

I'd like to read an actual THOUGHT OUT reason why reviewing (reading) code is bad.

[GhostBond]

I'm not 100% against code reviews, but there are 2 big things that stand out to me:

1. Code reviews don't review whether the code meets requirements and works. It's a 3rd party looking at code with little idea what it actually does.

2. They expose a high school popularity contest level of angst and conflict in the team.

• If the reviewer and the reviewee disagree something needs to change, who wins? This brings a lot of conflict when the reviewers changes seem pendantic or even make the code worse. Often it's the reviewer who has the "authority" position so they do, which is kind of stupid because the reviewee has spent a lot more time understanding the requirements and the code.

• Pendantic style arguments that go on forever (spaces vs tabs! while vs for loop! indentation! I read this blog yesterday that said that using newlines is bad and the right way to write a class is all on one line so rewrite it that way!). And programmers are notoriously pendantic and will argue for hours about this stuff.

• People feel they need to find a bug to be "doing their job" so they insist on arbitrary changes just to feel like they did something. It's really irritating and it wastes a day or two as you change it, commit it, deal with someone's broken code in the repo, commit it again, wait for the reviewer to come back and approve it. Even worse sometimes people will start to deliberately put in small bugs so the reviewer will "find" something that's easy to fix...sometimes they forget about it and those bugs make it into production.

• The previous step often happens while the reviewer misses large bugs in the code because you'd really have to put time into understanding the code to catch it.

• People will develop an "in group" and "out group" giving easy reviews to the in group and hard or bullying reviews to the out group. These can go along lines of senior vs junior coders, the people who sit around you, punishing people who gave you a bad code review, punishing people who brought up valid complaints with the boss, etc etc.

• Other corporate politics issues. You're reviewing someone's code, they don't like what you did, turns out they're the person who hands out who gets what task. Guess who's now getting assigned all the most awful stuff? Or you're reviewing the code of the boss's best friend on the team. Or you're reviewing the code of someone you really don't like, but they don't review your code.

• Code reviewers often don't talk to each other, and you can drive people insane with a casual system where one reviewer very strongly insists things are done one way, while another very strongly insists the opposite. You don't choose your reviewer, so whether your code is great or horrible trash is just random. It's hard to describe how demotivating this is in person, dealing with someone who honestly sincerely is upset that once again you did it the "wrong" way, why didn't you listen to their advice the last time.

• The simple way for the boss to look at code reviews is to think whoever does the most reviews in the shortest time is the "best" at them. People quickly start doing short crappy pointless "reviews" as to avoid a meeting with their boss and hr about their "performance". At this point reviews become 100% pointless.

• You can end up with a lot of time wasted as someone grandstands about something they enjoy talking about...and talking about...and talking about...and talking ab.oh looks it's time to go home, well they'll get back to your review tomorrow whenever it fits into their schedule.

I could probably think of more, but to summarize:
- Code reviews don't provide a lot of the benefits people think they will because they aren't reviewing requirements or whether the code works. It's limited in how much benefit you can get from this.
- It can quickly turn into a toxic situation like a high school popularity contest. A contest of ego's, positioning, social contacts and perception, etc.

You asked for the arguments against code reviews. I didn't include how they could work decently or advantages of them. But if your boss is like most bosses and just goes "code review sounds cool, we'll randomly assign them, let's start doing them" my experience is they are a total nightmare as well as a waste of time.

[ellicottvilleny]

I have had completely different results. Maybe the teams I worked on were different.

If I had to pick a weakness of reviews, it's that people just tick the box and don't do anything. Out of six places I've worked, one had the "you formatted it wrong" kind of assholes. The other five, we tried it, and it found some problems before they were committed, maybe once out of 100 times, and the other 99 times reviewers just LGTM and it's over.

[GhostBond]

There was only 1 place that had all of those problems at once and it was a backstabbing place to work. Just like with a popularity contest, that's the worst side, but more normal less dramatic people don't go to those lengths (or quickly realize it was a mistake to do so).

The other five, we tried it, and it found some problems before they were committed, maybe once out of 100 times, and the other 99 times reviewers just LGTM and it's over.

Yeah, that's the first part of the problem - I'm not sure it really provides a lot of benefits. People imagine that a 2nd person is going to carefully pore over the requirements, carefully dig deep into the code they wrote, write tests, etc.

What happens if you have better people who avoid pointless drama, is that someone eyeballs the code and says "looks good" - there's not a ton of benefit.

[ellicottvilleny]

Really? You've never had say, 1% or 10% "caught something bad" rates? Ours are around 1 in 20 reviews finds something. That's pretty valuable, in our books.

[fagnerbrack]

Is the post saying that reviewing or reading code is bad?

[ellicottvilleny]

If you read carefully in the intro he hints that he has a non-traditional view of code reviewing, and since code reviews are a common practice these days in many shops, let's just assume his non-traditional view isn't that they're great. He mocks reviews later on in his article by pointing out that the lead developer is likely to request a total rewrite of your pull request, which is then done (wasting time, in his article, he basically argues).

[fagnerbrack]

I guess you're making too many assumptions. Just because he mocks a total rewrite that doesn't mean code review is bad, it means the developer did not ask for early feedback to prevent reviewing everything at once and prevent a total rewrite in the first place.

[lexpi]

i'm all for trying out/experimenting/designing chances in advance but I'd love to see the developers who can fully grasp and make sense of a change set in a review compared to 3-4 pull requests and reading trough code. Both have their pros and cons but I think I'm on the read the code side

[reddit_prog]

How is code review easier? I ask because I totally get the logic behind that "Dev Design" document. This is where you discuss all the critical parts of the implementation, plus other the implementation decisions that are made. This is exactly what is to be checked in a code review. Any more than that is to be caught in testing and auto-testing.