6 ms·
> It's small teams that were together from the start. Going through the initial setup of a project makes all the difference. When people come later, they lack t
by tolien 8y ago
> It's small teams that were together from the start. Going through the initial setup of a project makes all the difference. When people come later, they lack the intuition that comes with being around when all the structural decisions were made. Early people make tradeoffs and bake good and bad practices into the pipeline, later people are told not to touch certain things because it's more complicated than it looks or will break something else that doesn't seem explicitly connected.
I've also seen this happen and agree with your analysis that it's probably not related to the programming language - it seems more like a problem with how the thought process behind those decisions is (not) recorded.
Short of making every project (and the codebase it results in) live for a short enough time to guarantee that nobody new will ever have to look at it, we've got to collectively do a better job of being able to explain the "wtf did you do that?!" aspect of development.
- akavel 8y agoYour last sentence reminded me of "The only valid measurement of code quality: WTFs/minute": https://www.osnews.com/story/19266/wtfsm/ https://www.osnews.com/story/19266/wtfsm/
- pishpash 8y agoA readme (in plain language) in every folder helps a lot. Either that or it's replaying every commit from the start. Maybe tools can be made for this.
- akkartik 8y agohttp://akkartik.name/post/wart-layers http://akkartik.name/post/wart-layers As it happens, my current project that uses it has a Readme in every folder: https://github.com/akkartik/mu https://github.com/akkartik/mu
- tolien 8y agoI don’t think it’s about tools as much as culture - whether it’s a readme, a wiki or a chat log that’s not full of talk about the weather and scones (no, really), people have to be suitably incentivised to work that way. Something that isn’t a customer-deliverable (they aren’t going to directly care if you don’t record the weird business process that led to you implementing feature X the way you did; they don’t have a comparison which tells them that if it was recorded, changes could’ve been quicker/cheaper/less risky) is at risk of being cut as soon as there’s a hint of time pressure to get something out the door. It’s coincidental that doing things in less of a “let’s all get in a room and talk about it for 3 hours” way should make keeping remote workers in the loop easier too.
- akkartik 8y agoI've been chasing project longevity (particularly in infrastructure like languages and OSs) for a long time, and came up with a prerequisite: http://akkartik.name/about http://akkartik.name/about This quest took me from programming in Lisp, to C, and now to raw machine code. I'm hoping to build back up to high level languages, but with key implementation features that enable outsiders to comprehend a codebase. https://github.com/akkartik/mu/blob/master/subx/Readme.md https://github.com/akkartik/mu/blob/master/subx/Readme.md