Timeline for Is it better to use frameworks with strict structural requirements?
Current License: CC BY-SA 4.0
18 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 19, 2020 at 6:00 | history | tweeted | twitter.com/StackSoftEng/status/1218775242845442048 | ||
| Jan 13, 2020 at 11:21 | answer | added | Rob | timeline score: 0 | |
| Jan 13, 2020 at 10:31 | answer | added | JayZ | timeline score: 1 | |
| Jan 12, 2020 at 18:36 | comment | added | Vilx- | @FilipMilovanović - I think I might have put it wrongly. We do not have a communication problem - we easily talk to each other when we need to, and there's no chain-of-command or anything. Recently there was one task which had a lot of cross-dependencies between three of us, and we spent a lot of time in Slack, going back and forth with what each of us needs of the others and what problems there are. What I mean is... there's no time allocated for things like "refactoring" or "mentoring" or "learning" or whatever... Although we're also free to do so if we want to, come to think of it... | |
| Jan 12, 2020 at 18:14 | comment | added | Filip Milovanović | I'm not saying your colleagues are bad, just that any team can always learn more, and that skill levels (various aspects) are generally disparate (people have different strengths and weaknesses) and that you would benefit as a team from more actively learning from each other. Also, nothing beats direct communication when it comes to organization, so this is not about "not-directly-related-to-task things", this is about a team trying to work more like a team on those tasks, rather then as a group of individuals each doing their own thing. | |
| Jan 12, 2020 at 18:06 | comment | added | Vilx- | @FilipMilovanović - I also cannot say anything bad about the skill levels of my colleagues. They're all good professionals who do their work very well and have a firm understanding of the craft. | |
| Jan 12, 2020 at 18:04 | comment | added | Vilx- | @FilipMilovanović - That might be, although I have no personal experience with any of this. 99% of the time each developer just gets assigned an individual task and does it to their best of ability. Sure, talking exists when their code needs to interact with other people's code, but spending time for the... how to put this... not-directly-related-to-task things is pretty rare. | |
| Jan 12, 2020 at 17:56 | comment | added | Filip Milovanović | "to synchronize people" - that's better achieved by having everyone on the team be an active participant, having the team agree on conventions and approaches of their own making and based on their own understanding of the problem domain, bringing everyone on the team to a certain skill level, using techniques like pair programming (e.g., a couple of hours of pair programming each day), etc. | |
| Jan 12, 2020 at 17:53 | comment | added | Filip Milovanović | BTW, you can say "no", or rather, discuss with the end users the utility of the requirement, the cost of implementing it, and negotiate it - sometimes requirements come in, and they aren't really well thought out, or seem like a "cool new feature" but do not provide much value to the end users, but are potentially a pain to implement (i.e., they are "costly"). Perfectly fine to rethink them or reject them - that's why you have things like iterations/sprints and backlog grooming. | |
| Jan 12, 2020 at 17:53 | comment | added | Vilx- | @FilipMilovanović - This echoes my own sentiments, however there is also a good argument for their viewpoint, beyond it being a crutch. When there are multiple developers working on a single project, they need some common guidance, otherwise the project becomes a hodgepodge of different development mentalities. I've seen this happen too, and on my own "unopinionated" projects no less. And it's not that someone is stupid, but simply each person prefers their own way. A common framework is actually helpful in this case, to synchronize people. | |
| Jan 12, 2020 at 17:48 | comment | added | Filip Milovanović | "They prefer the megaframeworks precisley because they enforce their structure and order upon your program" - that's because they use them as a crutch and because it blinds them to the limits of their own design skills. Frameworks help you get started quickly, and that's OK - but if that project is going to live on and grow, then following The Way prescribed by the framework, and relying on the framework structure and conventions too much, couples you to the framework and its limitations - and to the whims of the framework authors. | |
| Jan 12, 2020 at 8:45 | review | Close votes | |||
| Jan 19, 2020 at 3:00 | |||||
| Jan 12, 2020 at 7:39 | answer | added | Theodoros Chatzigiannakis | timeline score: 3 | |
| Jan 12, 2020 at 1:29 | comment | added | Vilx- | @RobertHarvey - EXACTLY! | |
| Jan 12, 2020 at 0:26 | answer | added | Robert Harvey | timeline score: 8 | |
| Jan 12, 2020 at 0:08 | comment | added | Robert Harvey | And then say "no" when a requirement comes in that cannot be reasonably accomplished due to the limitations of said framework? -- In what universe would that be a valid option? | |
| Jan 11, 2020 at 23:49 | history | edited | Vilx- | CC BY-SA 4.0 | added 362 characters in body |
| Jan 11, 2020 at 23:33 | history | asked | Vilx- | CC BY-SA 4.0 |