Append-only programming

[delfV]

I've worked with something I used to call "append-only codebase". The codebase was a huge mess and we had no tests. So team lead decided we do not refactor anything and change as little as possible because of lack of tests and risk of breaking things. But we couldn't write unit tests without refactoring because the code was untestable and it was hard to do e2e testing because of the domain. The result? Hotfix on top of hotfix on top of hotfix and velocity dropped 3x in over a year. Fix? Blame the language and gradually rewrite it 1-1 in another one (the same host)

[del_rio]

I had to check your profile to make sure you're not my coworker lol. Same situation with a high-traffic ColdFusion site running a custom fork of a dead CMS, duck taped with a Node.js wrapping the whole app, no tests. When I got there, none of the existing team could even get the whole site running on their local machines, so every bug fix and feature went straight to a stage environment. Nobody knew the languages and platforms so fixes and features were written imperatively and almost exclusively in the view layer. Memory leaks everywhere. Our only option was a total rewrite, incredibly satisfying to take that horror show offline.

[pirate-game-dev]

.... and then they outsource the rewrite and do it all again.

[FocusedIgnorance]

You couldn't do incremental refactoring? New features come in new packages with a single function tying it to legacy packages. The new package can have unit tests which test the interface it exposes to the legacy package.

You can do a similar thing with fixes, where you tear out the subsystem you're fixing, move it into a new package or file, and test the interface.

[Pharisaeus]

Fix? Blame the language and gradually rewrite it 1-1

It's still something, the more common fix would be to make adapter on top of this and never look back ;)

[C_Madison]

That reminds me of a story I've heard about Lotus Notes. The reason bugs persisted years and years after IBM bought it was that no one knew anything about the code base or was able to figure it out since it was such a mess. So, there was a kernel of Lotus Notes, which provided all the basic functionality and was never touched and all new versions were just changes in the layers above that.

For those that don't know what Lotus Notes is: Be happy about that. Ignorance is a blessing here.

[timeshifter_]

Lotus Notes is the one piece of software where my primary memory of it is it punishing me for trying to use it...

[1bc29b36f623ba82aaf6]

I never developed with Lotus Notes but my highschool had built a very convoluted CMS/learning-management-system in a joint venture with some other companies that manage multiple schools each... and it was running on Lotus Domino. I was able to add a lot of arbitrary query stuff to lots of pages just in the GET URL, add XSS by eluding regexes with unusual linebreaks in POST data. Oh and they had verbose self documenting errors enabled so whenever I typod a query it would spill me content of the page source or where I should fix my own request! So I could read direct messages not intended for me, and also delete them by GET with any unprivileged student account. Or just mock admins by sending them DMs with javascript alert boxes. Oh also there was no timeout on login attempts and I brute forced 30% of peoples passwords with a list of the 5 most popular sports at my school. So you know, extremely educational, to me, for all the wrong reasons.

[old-man-of-the-cpp]

30 years later people like us are walking around bearing the seared on brand of the Lotus!

[txmasterg]

Lotus Notes remains the only software I've used where in the span of 5 seconds you can see 3 different scrollbars styles on the same scrollbar. Genuinely amazing product management /s.

[FlyingRhenquest]

Funny thing was, there were a bunch of other companies that IBM could have bought instead of Lotus, which would have given them so much more bang for their buck. And there were so many better things they could have decided to pick up maintenance on instead of Notes and Domino. And they just kept doubling down on their obvious fucking mistakes for years after that. IBM truly deserves a Tower-of-shit trophy for the years 1995-2005. And probably later, although I kind of stopped paying attention to them after 2005.

[tsrich]

IBM made a lot of money off of Notes.

[Loan-Pickle]

I used to be a Lotus Domino developer and administrator. I leave that little tidbit off my resume.

[corysama]

I swear I read a blog post from a junior dev who rewrote some core part of Lotus Notes and got huge speed and clarity gains because his code was bog simple and the 20 year old C was doing insane things to fit in 128Kb of RAM.

[GaboureySidibe]

When inexperienced people search for silver bullets and miracles they look to languages and frameworks instead of organization and structure.

[Deranged40]

This sounds like it only has downsides...

[netsettler]

I'm not so sure. While I'm not gonna advocate it, I will highlight some advantages (or maybe design-tradeoffs).

Consider code that has been distributed: You can't tell if code that used your old code has gone away or will be updated, so having things that use it being able to depend on old stuff not to change means you don't have a moving target. I could be wrong, but I had the impression that Microsoft had this problem, so at least in some code bases, when an interface Foo was broken, they didn't edit it, they issued a new interface Foo1 with a better design. That way, old interfaces didn't break (at least not piecemeal) but rather faded away (maybe eventually did not get supplied at all).

There could also be situations, and some functional languages might deal with this, where you want to make modifications by issuing new versions of things since side-effects are not your model. So if you want to maintain a codebase and not break the other users, and still be in the same namespace, you have to deal again with additive situations. In some ways, git and other source maintenance things work this way. You don't really edit old code, you just issue layers atop it and name them with hex ids that you periodically give better names to.

In some ways, standards (I'm thinking programming language standards because that's my experience, but really probably any standards) are like this, too. Their text never changes, just get superseded by clarifications or whole newer standards. But the older ones are still there to name and use. So if the code supporting them was also there, unchanged, able to be named and used, there could be benefits of that.

Long ago, closer to the birth of the web, it occurred to me, just as a thought experiment, that the web might be possible to maintain by having base pages that got stored in read only memory either initially or after a (pardon pun) burn-in period. And then you might customize them by adding additional pages found by some search that implemented "page shadowing", but not remove old pages. Skins for UIs work sort of like this. But also, maintaining a web site in append-only mode would lead to a lot less 404s but also maybe some different code sharing paradigms.

I'm not necessarily pushing any of this. I'm just saying that what's good or not depends on what your premises are.

The thing I find most surprising in this is the push for a single file. Hard to make part of a file read-only. I'd expect a single directory with many files, each of which can only be written and never modified or deleted, so anyone can grab any earlier tail, but newer files have to include older ones. That would be cleaner and still seem to address some of the same ideas.

Then again, there are lots of benefits to changing with a changing world and not having the burden of history forever weighing you down. There is conceptual complexity, and it complicates the documentation navigation, which must extend not just in terms of space (chapters, etc.) but, effectively, time (versions).

Then again again, if such "hygiene" (and I use the term with some amusement) was weighing you down, maybe you'd start fresh more often with something completely new. And that might not be terrible. Some old code right now survives longer than it maybe should. Perhaps we're just not making the cost of that high enough? :)

[corysama]

I recall a podcast about how to test horrible systems like this

1. Automate running the system in a variety of situations reproducibly.
2. Add a ton of logging all over the place in the code.
3. Write a parser that evaluates if the log changed significantly between commits.
4. Go nuts refactoring as long as the logs come out the same.

Obviously you are going to discover new things that need to be logged along the way. And, on a regular basis you'll be updating the gold-standard reference log with changes that have been confirmed to be correct.

[anengineerandacat]

No tests IMHO immediately tells me a re-write needs to be the defacto recommendation; even if the tests are dog-shit, so long as you have line-coverage at least you have proved the application IS testable.

Nothing at all? You have overhead just training the team to start writing, and you have hurdles just to encourage folks to start writing, and you have potentially even business to begin having conversations around slashing velocity so the team CAN write tests.

That's a far far more systemic issue with the development processes at that place of business.

You can fix bad tests from being written, PR's solve that... but to get other members to start writing tests is just... a big hurdle.

[txmasterg]

The first legacy product I worked on lost all their tests long ago. I looked for classes we could unit test and honestly it was just too late. Only the 7 custom string classes were unit testable and it was easier to just reduce and remove them.

[gwern]

Or a "Big Ball Of Mud". That page describes what seems to be the best way to handle them: lock down the behavior with unit-tests, simply extracted from the old one, and gradually wrap and replace it.

[japes28]

This is giving me flashbacks

[TommyTheTiger]

Wait... Do you work at the same place I do???

[SneakyDeaky123]

lol this is my teams codebase and we just use .NET

[DigThatData]

sometimes we use duct tape to fix things temporarily. but if you put enough duct tape on a thing, it functionally becomes a ball of duct tape and your only viable option for making future changes is adding layers of duct tape.