Update modular-code.md #95

ErinMB · 2018-03-30T16:59:25Z

Erin, Tim & Keerthi revised various sections. Team - please review!

rrrutledge

Some comments that I think make sense to address, but
also approving as the submitted document seems to be in as-good or better state than the master document.

rrrutledge · 2018-04-02T10:30:10Z

modular-code.md

@@ -11,36 +11,49 @@ Development does not want to spend the extra resources needed to develop modular
 * Time commitments might already have been made for customer deliveries (not changeable).

 **Forces:**
-* There is a learning curve to writing code that can be reused.
+* There is a learning curve to writing code that can be reused. Developers might not know how to write modular code. Education might be needed.


Not a huge deal in this case, but recommend putting each sentence on its own line.

rrrutledge · 2018-04-02T10:30:10Z

modular-code.md

@@ -11,36 +11,49 @@ Development does not want to spend the extra resources needed to develop modular
 * Time commitments might already have been made for customer deliveries (not changeable).

 **Forces:**
-* There is a learning curve to writing code that can be reused.
+* There is a learning curve to writing code that can be reused. Developers might not know how to write modular code. Education might be needed.


Education might be needed.

Feels like a potential solution rather than a force?

Good catch (and education is indeed part of the solution). We can probably delete the sentence (Education might be needed).

rrrutledge · 2018-04-02T10:30:10Z

modular-code.md

 * Might be a fear that if not done properly, quality might be impacted.
 * Developers might not have incentive to write modular code (due to their tight schedules and lack of a mandate).
 * You might be dealing with legacy systems (can't be simply refactored or rewritten).
 * Requirements might be different for writing modular code.
 * Architectural constraints might impact modularity.
 * Developers who develop monolithic code bases might lack the perspective of how modularity might improve how they work.
+* If there is frequent turnover of team members, modularization may not be a priority.


I don't understand the connection between these ideas. Modular code seems even more useful with rotating team members so that no one has to keep the whole monolith in their head?

@rrrutledge, the experience shared was that in a team with frequent turnover, the emphasis (sadly) wasn't on producing more maintainable code but in struggling to meet deadlines (no bandwidth for making their code more modular).

I'd say that's less about turnover of team members than just under short-term time pressure in-general. Could be for a variety of reasons but we'd expect to see that result no matter what outside force is driving that pressure.

rrrutledge · 2018-04-02T10:30:10Z

modular-code.md

 **Author:**  
+Tim Yao, Nokia


Needs bullets or something else to make each name appear on its own line.

spier · 2020-03-18T19:03:35Z

I changed the headline formatting of this file as part of #131. So if that branch get merged, we will likely see a bunch merge conflicts with this branch.

rrrutledge · 2020-03-18T23:28:59Z

Oh well - this PR is nearly two years old 🤷‍♂

lenucksi · 2020-08-10T15:59:24Z

I've merged the master branch into to pull request to enable it to merge cleanly. Luckily @spier's great re-sorting pull request had this sorted into 1-initial already.
I'd love to merge this but would appreciate if @NewMexicoKid and @rrrutledge could have a look into the open discussions and resolve them if ready or see into getting them resolved.

rrrutledge · 2020-08-10T16:24:32Z

Great! Will take a look.

rrrutledge · 2020-08-10T22:44:40Z

None of my discussions are resolved. I already signed off, though. I don't think that my comments should block merge.

gruetter

I think a couple of explanations are required. I'll approve, trusting that the shepherd of this PR will consider my suggestions.

gruetter · 2020-08-11T20:41:46Z