onion2kMar 17

But you can’t just not review things!

Actually you can. If you shift the reviews far to the left, and call them code design sessions instead, and you raise problems on dailys, and you pair programme through the gnarly bits, then 90% of what people think a review should find goes away. The expectation that you'll discover bugs and architecture and design problems doesn't exist if you've already agreed with the team what you're going to build. The remain 10% of things like var naming, whitespace, and patterns can be checked with a linter instead of a person. If you can get the team to that level you can stop doing code reviews.

You also need to build a team that you can trust to write the code you agreed you'd write, but if your reviews are there to check someone has done their job well enough then you have bigger problems.

Show threadalkonautMar 17

This falls for the famous "hours of planning can save minutes of coding". Architecture can't (all) be planned out on a whiteboard, it's the response to the difficulty you only realize as you try to implement.

If you can agree what to build and how to build it and then it turns out that actually is a working plan - then you are better than me. That hasn't happened in 20 years of software development. Most of what's planned falls down within the first few hours of implementation.

Iterative architecture meetings will be necessary. But that falls into the pit of weekly meeting.

Show thread2OEH8eoCRo0Mar 17

I've worked waterfall (defense) and while I hated it at the time I'd rather go back to it. Today we move much faster but often build the wrong thing or rewrite and refactor things multiple times. In waterfall we move glacially but what we would build sticks. Also, with so much up front planning the code practically writes itself. I'm not convinced there's any real velocity gains in agile when factoring in all the fiddling, rewrites, and refactoring.

> Most of what's planned falls down within the first few hours of implementation.

Not my experience at all. We know what computers are capable of.

Show threadorthoxeroxMar 17

> Today we move much faster but often build the wrong thing or rewrite and refactor things multiple times. In waterfall we move glacially but what we would build sticks.

That's an interesting observation. That's one of the biggest criticisms of waterfall: by the time you finish building something the requirements have changed already, so you have to rewrite it.

Show threadbudman1Mar 17

there is a difference between the requirements changing and the poor quality, quickly made implementation proves to be inadequate.

agile approaches are based on the quick implementations, redone as needed.

my favorite life cycle:
1> Start with requirements identification for the entire system.
2> Pick a subset of requirements to implement and demonstrate (or deliver) to the customer.
3> Refine the requirements as needed.
4> go to 2

The key is you have an idea of overall system requirements and what is needed, in the end, for the software you are writing. Thus the re-factoring, and re-design due to things not included in the sprint do not occur. (or occur less)

Show threadsbarre
This approach also accounts for the truism that "the customer doesn't know what they want until they don't see it in the final product".
Mar 17 at 4:05pmWeb