<div dir="auto">In addition to "software maintenance helps people", I would add that there's a real intellectual challenge involved. Perhaps less creative and more analytical than green-fields development, but personally I really enjoy identifying all the moving parts, figuring out how they fit together, and then rebuilding the plane while it is in flight.<div dir="auto"><br></div><div dir="auto">Upgrading a dependency version may be often rather dull, but refactoring a major component to make it more usable, readable, and, well, maintainable can be a high-wire act.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 22, 2020, 8:25 AM Andrew Russell <<a href="mailto:arussell@arussell.org">arussell@arussell.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><br><div><br><blockquote type="cite"><div>On Oct 22, 2020, at 3:37 AM, Bastien <<a href="mailto:bzg@bzg.fr" target="_blank" rel="noreferrer">bzg@bzg.fr</a>> wrote:</div><br><div><div>lee vinsel <<a href="mailto:lee@themaintainers.org" target="_blank" rel="noreferrer">lee@themaintainers.org</a>> writes:<br><br><blockquote type="cite">I think Andy's take was the report was "on point but a<br>bit boring."<br></blockquote><br>Isn't this the very definition of "maintainance"? :)<br><br>If I may use this tangent to open a new discussion: how can we change<br>the overall perception of maintainance as "boring"?<br></div></div></blockquote><div><br></div><div>To be clear, my ‘take' was tongue-in-cheek. I think Bastien is exactly on the right track - stories are more or less engaging to the extent that authors know their audiences. One should not expect a character-driven drama from a McKinsey report on “The future of maintenance for distributed fixed assets”; just as one should not expect a data-driven assessment of IoT to be published in, say, <i>The American Poetry Review</i>. But one beautiful thing about maintenance is that it’s an engaging topic for both audiences (and so many others). The challenge comes in how one frames the discussion. </div><div><br></div><div>A big +1 to Bastien’s last word (below)</div><div><br></div><div>"I strongly believe that we need to tell a different *story* about maintainance - and actually a million ones.”</div><div><br></div><div>Andy</div><div><br></div><div><br></div><br><blockquote type="cite"><div><div><br>I guess it really depends on the fields.<br><br>I have recently discovered the "Technical Debt Quadrant", from reading<br>this interesting blog post:<br><br><a href="https://somehowmanage.com/2020/10/19/manifestations-of-technical-debt/" target="_blank" rel="noreferrer">https://somehowmanage.com/2020/10/19/manifestations-of-technical-debt/</a><br><br>I think each part of the quadrant nicely captures what it means to<br>maintain a software (not the service it runs, the software itself):<br>the only quadrant you want to find yourself in is the "prudent" one,<br>where you only have to "deal with the consequences" (here again, a<br>nice periphrase for "maintainance".)<br><br>That said, "dealing with the consequences" still sounds negative and<br>quasi punitive. You spontaneously represent yourself dealing with<br>things retroactively, paying a debt.<br><br>BUT, my experience with software maintainance is a bit different.<br><br>1. It is more about PEOPLE than "things": a user reports a bug and you<br> fix it, it will help this user, that's motivating. Maintainance in<br> Free software is also all about helping others help you, which is a<br> difficult but interesting skill to nurture.<br><br>2. FLOSS maintainance is more about investing than reimbursing. Of<br> course, you may have to literally suffer when you need to do some<br> boring refactoring and dependencies management... but sometimes you<br> are excited by the challenge of redoing things in a better way, and<br> seeing this move as an investment to find yourself in the "prudent"<br> quadrant again.<br><br>That's the way I would argue that free software maintainance is NOT<br>boring.<br><br>What would be yours in your field?<br><br>I strongly believe that we need to tell a different *story* about<br>maintainance - and actually a million ones.<br><br>-- <br> Bastien<br>_______________________________________________<br>Themaintainers mailing list<br><a href="mailto:Themaintainers@lists.stevens.edu" target="_blank" rel="noreferrer">Themaintainers@lists.stevens.edu</a><br><a href="https://lists.stevens.edu/mailman/listinfo/themaintainers" target="_blank" rel="noreferrer">https://lists.stevens.edu/mailman/listinfo/themaintainers</a><br></div></div></blockquote></div><br></div>_______________________________________________<br>
Themaintainers mailing list<br>
<a href="mailto:Themaintainers@lists.stevens.edu" target="_blank" rel="noreferrer">Themaintainers@lists.stevens.edu</a><br>
<a href="https://lists.stevens.edu/mailman/listinfo/themaintainers" rel="noreferrer noreferrer" target="_blank">https://lists.stevens.edu/mailman/listinfo/themaintainers</a><br>
</blockquote></div>