5 ms·

> Is analysis - reading and thinking about what code does - no longer considered feasible? "Not shipping" and "ensuing mass layoffs followed by bankruptcy" are

> Is analysis - reading and thinking about what code does - no longer considered feasible? "Not shipping" and "ensuing mass layoffs followed by bankruptcy" are still considered feasible. I kid, I kid. A few thousand lines of code in isolation? Piece of cake, I can grok it within the hour. Ten lines of WTF intertwined within a multi-million LOC codebase making judicious abuse of reflection, TLAs, and layer upon layer of misnamed abstractions which do something subtly different from what you expected - using three technology stacks spanning three decades of changing idioms and trends in software development - written in a 'mission critical' culture where bugs are intentionally kept as backwards comparability features? Three people will claim to understand the code well enough to make changes within a week: The rookie, the madman, and the asshole who wrote it. If you're lucky, none of them still work there - based on the number of bugs increasing when "fixes" are applied, it's clear none of them do, or ever did. Priding myself on being only half mad, I will claim to understand 5 out of 10 of those lines within a week. If I'm lucky, they'll even be the 5 lines I need to modify for your feature request. Based on my vague understanding of the few tens of thousands of lines of code these 5 lines interact with, I can assure you I am half certain[1] that I probably didn't break anything [2]. [1] Read: Half uncertain [2] Read: I'm assuming our QA team are not mere mortals, but are gods, and thus have at least a 50% chance of catching any bugs I introduced.

andrewaylett 11y ago
I've worked with that QA team. They really were that good, but unfortunately they really were that necessary. The real difficulty is that you've no way of knowing whether the WTF you're looking at is inappropriately placed (and completely undocumented) business logic, an actual bug or a seriously hacky workaround for a bug in a completely different area of the code. If a bug, it may well be itself worked around by a seriously hacky fix somewhere completely different, which will break horribly if you fix the issue here. If it's a fix or especially if it's business logic then then it's even odds that it's not required any more.
mannykannot 11y ago
My guess is that you are doing more analysis than you are taking credit for.
- MaulingMonkey 11y ago
  I'm doing a lot of analysis - that's how I came to posses a vague understanding of the few tens of thousands of lines of code those 5 lines interacted with. That's how the majority of that week was spent. Fortunately the codebases I work on are generally <1MLOC, <10 years of tech churn, had at least some decent coders helping keep technical debt from spiraling completely out of control, with management that will give them the time they need to manage that technical debt. So it usually takes more like 50 lines of WTF to confuse me to the point of needing over a week of basically pure analysis to untangle things. But I don't have enough time to perfectly understand the entire codebase and all it's dependencies. And it doesn't eliminate the need to manage the expectations of management. If they don't understand where things are at, even good managers will over-promise in their contracts (bad - enjoy crunch, slipped milestones, and missed payments!), under-promise in their contracts (bad - leaving money on the table), mistime their marketing campaigns, mistime their hiring pushes, plan the next project to start when the current one is just ramping up, fire the wrong people, hire the wrong people, hurt morale with unrealistic expectations... all kinds of nasty stuff.

andrewaylett 11y ago

I've worked with that QA team. They really were that good, but unfortunately they really were that necessary. The real difficulty is that you've no way of knowing whether the WTF you're looking at is inappropriately placed (and completely undocumented) business logic, an actual bug or a seriously hacky workaround for a bug in a completely different area of the code. If a bug, it may well be itself worked around by a seriously hacky fix somewhere completely different, which will break horribly if you fix the issue here. If it's a fix or especially if it's business logic then then it's even odds that it's not required any more.

mannykannot 11y ago

My guess is that you are doing more analysis than you are taking credit for.

MaulingMonkey 11y ago
I'm doing a lot of analysis - that's how I came to posses a vague understanding of the few tens of thousands of lines of code those 5 lines interacted with. That's how the majority of that week was spent. Fortunately the codebases I work on are generally <1MLOC, <10 years of tech churn, had at least some decent coders helping keep technical debt from spiraling completely out of control, with management that will give them the time they need to manage that technical debt. So it usually takes more like 50 lines of WTF to confuse me to the point of needing over a week of basically pure analysis to untangle things. But I don't have enough time to perfectly understand the entire codebase and all it's dependencies. And it doesn't eliminate the need to manage the expectations of management. If they don't understand where things are at, even good managers will over-promise in their contracts (bad - enjoy crunch, slipped milestones, and missed payments!), under-promise in their contracts (bad - leaving money on the table), mistime their marketing campaigns, mistime their hiring pushes, plan the next project to start when the current one is just ramping up, fire the wrong people, hire the wrong people, hurt morale with unrealistic expectations... all kinds of nasty stuff.