As an old software-dev who has both started and 'finished' projects (stayed on to make them actually useful in production for non-trivial data flows), Amen.<p>In today's world it is in some ways getting worse: You have older applications that are still bringing in money, built on a patchwork of outdated platforms, that e.g. Microsoft no longer supports or offer migration paths away from, apart from a full rewrite.. And unpatched security holes in the older software removes your option of 'just stay'.<p>I find it painful to explain to business that yes, their 5-6 year old 'greenfield' product now consists almost entirely of parts that no longer offer migration paths or maintenance :-/.
The author makes this point only somewhat implicitly, but I think for a lot of people, new feature development is the <i>fun</i> part of software engineering. Not for everybody (do not let me tell you how to have fun), but a substantial majority. A project's maintainers might <i>also</i> have lots of ideas for new features they would love to work on, but if 9 out of 10 people want to spend their time adding features, and adding the feature is only 10...25% of the work, you can see there is a problem.
I tend to be picky about code reviews. I'm aware that it causes friction and can come across as unreasonable. It works, we're done, right? Well it's likely to be my problem to maintain this code at some point in the future. Overly complicated? Unstated assumptions? Lack of test coverage? Fits well with nearby things? Solving a problem is fun but software engineering is more than just the fun parts.
Even the simplest of projects have these engineering challenges, but people cannot see the forest for the trees when it comes to maintenance.<p>Since I did not enter the industry with a computer science degree, I was relegated to less desirable maintenance work for the majority of my career. I have twenty five years of experience reading other people's sometimes great, frequently benign, and occasionally really bad code.<p>Unfortunately, most of my experience is wasted and not well respected. Most people do not care to look far ahead, they are far too consumed with 'just getting it up and running'. It's all engineering in the end. The house building analogy holds. Make smart tradeoffs. Don't paint yourself into a corner. Build exits for yourself: from platforms, APIs, libraries, and seldom trodden code paths. If you can write it yourself and it's not that complicated, write it yourself. Dependencies are a nightmare from a security and long term use perspective. They might be good for starting out, but you really have no idea where your project and organization will take you.<p>If I were a hiring manager I would value this experience more than anything else. It's nice if you can bang out some algorithms, but I think it's much more useful for most organizations if you can make forward-thinking engineering decisions.
But always protecting the maintainers' best interests over those of users or new contributors ultimately leads to the death of the project.<p>There's a fairly good chance the reason someone wrote that 10k line PR is because they actually understand the problem users are having, and you don't as a maintainer.
“… found it extremely difficult dealing with bug fixes and feature requests relating to the other developer's code, who used a substantially different coding style. In the end we had to rewrite all our plugins for Construct 3, and so we ended up rewriting all the code anyway, which was particularly challenging given we hadn't written it ourselves in the first place and didn't have a deep understanding of how it worked. It's far easier now it's all our own code.”<p>I love this article and agree with almost all of it. However, this portion I find to be guilty of elitist programming mantra.<p>The bottom line is when you’re dealing with large code bases, there will be different coding styles present and the likelihood of everyone agreeing on a single coding style is virtually nil. Insistence on coding purity is an issue that can erode camaraderie in a team and develop into petty political in-fighting. Handling this problem in a tactful way is one of the keys to success in large code bases, as developers have their own styles and draconian insistence upon a single style can limit the talent that’s willing to work with you and your team.
As a 19-year Chromium dev, this rings true and highlights a lot of reasons "why don't you just..." is rarely the start of a good suggestion.
Speaking as someone who has been working on a system for almost 10 years now (and it's a programming language and UI framework) the amount of times I have seen "this was so easy, we did it two days with three people" proof-of-concepts that <i>legitimately</i> ballooned into "a team of eight devs, two quarters of work" when actually funded makes me say that <i>even the 10K line pull request</i> probably isn't a valid measure of "the work". There's so much more to shipping a useful software facility than just the actual function "A -> B". How does this system interact with other systems (since the world is not actually a pure function side effects from pure functions are in fact observable), how does anyone know to use the new thing, what happens when the sub-systems this system depends on are in a degraded state, and so on and so on and so forth. If you don't solve these problems (or at least guard-rail them) before shipping then whoever owns them after shipping will have to solve them.
One aspect not covered is how varied and wide ranging across the code and deployment platforms maintenance is done. One day you are tracking down a problem that's found to be caused by picking characters from UFT strings using indexes, and the next day the problem was an asynchronous job assuming all exception sub-classes of a common super-class can be ignored. These context switches physically hurt.
> writing the initial code for a feature is about 25% of the total work involved for that feature.<p>Over a decade ago, I had a job where we were juggling several projects and needed to track our work in 15 minute intervals. The timesheets were mildly annoying but they did allow us to determine that number empirically.<p>We came up with an average ~20%. Remarkably little variation across projects too.<p>The implications to estimation should be obvious - any software planning process that resembles a feature factory and only estimates 20% of the work is systematically neglecting the remaining 80% - things like fixing bugs, performance optimization, backup drills, dealing with dependencies, code review, CI/CD/Release process, QA testing, docs, UX testing, training, technical communication, etc. Multiplying the initial estimate by 5x is not just some cheeky heuristic to pad estimates, it's damn near proven by empirical evidence IMO.<p>Constantly shoving more and more features into software systems without doing any of the engineering work to support it leads to bad outcomes. Who could have guessed /s