4 ms·

This was interesting to read as a more "junior" software dev. Aside from Agile, what are other common frameworks that people use, if any?

cricketlover 2y ago
there's kanban
kylestlb 2y ago
Agile isn't a framework, it's just a set of principles. Scrum is a loose framework theoretically based off of those principles with some ground rules that can be broken depending on what works for your team. Same with Kanban.
smokel 2y ago
The "waterfall" way of working still has some merit. Think first, then make a design, and a planning based on that, and then implement the fucking owl. Unfortunately, a lot of unforeseen problems show up during the implementation phase, and people blame the waterfall model for not being flexible (agile) enough to address these. Now, even more unfortunately, some people interpret agile as not needing to spend time upfront thinking and dive into the implementation straight away, creating an even bigger mess than the waterfall generation could have ever imagined.
- exe34 2y ago
  > Unfortunately, a lot of unforeseen problems show up during the implementation phase, and people blame the waterfall model for not being flexible (agile) enough to address these. my experience is that people spend half the time bikeshedding the obvious problems that waterfall would have identified in much less time, and then still hit the unforeseeable problems after implementation anyway. if they could have been foreseen, they would have been rolled into waterfall.
beryilma 2y ago
Extreme Programming used to be a thing. Pair programming and all that... Not so much anymore.
- drewcoo 2y ago
  Pair programming does not lend itself well to micromanagement.
plantwallshoe 2y ago
The last 2 companies I’ve worked at (one massive one tiny) both didn’t use any framework. Engineers/PMs/Managers worked together to figure out what to build and the engineers built it. The only “tool” was trust and it worked out fine. We did a short daily or weekly status update to let everyone know how things were going, but that’s about it. Some engineers liked to break out work into pieces and put that into a spreadsheet, but it was completely up to the builder to decide how to organize their work. When a notable piece of work got finished the engineer would demo it to the team/company so more people could see how it was going.
- BerislavLopac 2y ago
  Out of curiosity: 1. How did you define the scope of "what to build"? Did you have tickets, or some less formal specifications like wiki pages, or simply a verbal agreement? How did you ensure that everyone's on the same page? 2. How did you track the progress of "building a thing"? Did you have some kind of "statuses", or each work basically had only two states -- "not done" and "done"? 3. How did the engineers coordinate on their work? Or every "thing to build" was always done by one single engineer? If the latter, how was it later maintained - always by that same person or did others work on it as well? Please note that I don't mean to demean your experience -- these are simply issues that pop up in software engineering, and decisions have to be made how to approach them. And not making a decision is also a decision.

cricketlover 2y ago

there's kanban

kylestlb 2y ago

Agile isn't a framework, it's just a set of principles. Scrum is a loose framework theoretically based off of those principles with some ground rules that can be broken depending on what works for your team. Same with Kanban.

smokel 2y ago

The "waterfall" way of working still has some merit. Think first, then make a design, and a planning based on that, and then implement the fucking owl. Unfortunately, a lot of unforeseen problems show up during the implementation phase, and people blame the waterfall model for not being flexible (agile) enough to address these. Now, even more unfortunately, some people interpret agile as not needing to spend time upfront thinking and dive into the implementation straight away, creating an even bigger mess than the waterfall generation could have ever imagined.

exe34 2y ago
> Unfortunately, a lot of unforeseen problems show up during the implementation phase, and people blame the waterfall model for not being flexible (agile) enough to address these. my experience is that people spend half the time bikeshedding the obvious problems that waterfall would have identified in much less time, and then still hit the unforeseeable problems after implementation anyway. if they could have been foreseen, they would have been rolled into waterfall.

beryilma 2y ago

Extreme Programming used to be a thing. Pair programming and all that... Not so much anymore.

drewcoo 2y ago
Pair programming does not lend itself well to micromanagement.

plantwallshoe 2y ago

The last 2 companies I’ve worked at (one massive one tiny) both didn’t use any framework. Engineers/PMs/Managers worked together to figure out what to build and the engineers built it. The only “tool” was trust and it worked out fine. We did a short daily or weekly status update to let everyone know how things were going, but that’s about it. Some engineers liked to break out work into pieces and put that into a spreadsheet, but it was completely up to the builder to decide how to organize their work. When a notable piece of work got finished the engineer would demo it to the team/company so more people could see how it was going.

BerislavLopac 2y ago
Out of curiosity: 1. How did you define the scope of "what to build"? Did you have tickets, or some less formal specifications like wiki pages, or simply a verbal agreement? How did you ensure that everyone's on the same page? 2. How did you track the progress of "building a thing"? Did you have some kind of "statuses", or each work basically had only two states -- "not done" and "done"? 3. How did the engineers coordinate on their work? Or every "thing to build" was always done by one single engineer? If the latter, how was it later maintained - always by that same person or did others work on it as well? Please note that I don't mean to demean your experience -- these are simply issues that pop up in software engineering, and decisions have to be made how to approach them. And not making a decision is also a decision.