3 ms·
> Waterfall vs agile is not really about how much effort you put into design, it’s about how long the plan-code-reassess cycle is. Read the Manifesto again. Yo
by randomdata 4y ago
> Waterfall vs agile is not really about how much effort you put into design, it’s about how long the plan-code-reassess cycle is.
Read the Manifesto again. You will notice that is actually about the considerations you should take into account if you want to run a software team without managers. Each point is there to ensure that the necessary functions a manager would traditionally take care of still get done.
Waterfall never existed as some kind of formal process. It was invented as an illustrative device.
- torben-friis 4y ago> Read the Manifesto again. I did, and here's the direct quotes: > Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. As I said, the cycle length is shortened, yet... > Continuous attention to technical excellence and good design enhances agility. ...design is not removed from the process, but kept as a cornerstone. > Simplicity--the art of maximizing the amount of work not done--is essential. This one might be a bit more of a stretch, but I see here the benefit of designing a simple, elegant solution rather than doing work straight ahead. In any case, I don't fully agree with the agile manifesto, even when correctly implemented. Particularly this quote is the bane of my existence: > The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Which you can identify as the very opposite of the ever popular 'this meeting could have been an email'.
- randomdata 4y agoNow read it again as the entire document that it is. While I can see where you are coming from, your theme doesn't carry into the points you conveniently left out. Once you put it together, you'll realize that the message is: 1. Deliver software. You won't have a manager hounding you to do so. 2. Do good work. You won't have a manager questioning what you've done. 3. Don't spend more time programming than you need to. You need time for managerial tasks. 4. Meet with your teammates. You won't have a manager to act as the go-between.
- TheRealSteve 4y agoBeing a developer without a good Engineering Manager is a futile exercise in my experience. Software developers deliver quality work and solve problems efficiently as a matter course. If not, they should be let go to work someplace else, potentially outside the software trade. Saying those skills are exclusive to followers of the agile manifesto is silly. Find a good manager that brings you opportunities and respects your expertise. If your manager hasn't put you in a place to be the rock star in the last year or so you need to move on or accept you aren't "all that". My opinion is based on being a software engineer (junior through principal) at small, medium, and fortune 100 companies. I also have years of experience as an engineering manager.
- Aeolun 4y ago> Saying those skills are exclusive to followers of the agile manifesto is silly It’s silly to be absolute about it, but I think there’s probably a large overlap between competent engineers and people that agree that the agile manifesto is generally a good thing.
- TheRealSteve 4y agoThat's fair. In that spectrum I'd rank folks that see agile as but one tool in the shed higher than those that agree it's _the_ way to execute projects.
- randomdata 4y ago> Saying those skills are exclusive to followers of the agile manifesto is silly. What says that? The Manifesto is there to help guide you if your group chooses to forego managers, but it doesn't suggest not having managers is the right tool for the job. An engineer more than anyone should understand the concept of tradeoffs.