5 ms·

> I don't buy this whole "nobody knows how to update the code" reasoning Me too. At best, they would need the previous guys only in one condition: very short t

> I don't buy this whole "nobody knows how to update the code" reasoning Me too. At best, they would need the previous guys only in one condition: very short time constraint (have to figure it out "today"). Otherwise, it's not hard to figure out at all, even codes from a complete idiot. If he can code the program that worked, the code is very likely be figured out by experienced people very soon.

commandlinefan 4y ago
> be figured out by experienced people Sure, you can figure out how to change it to do some very specific thing that somebody identifies as needed. What you probably can't do (at least not in any reasonable amount of time) is figure out all the things you're going to break in making this change. If they followed good software development practices, left a good comprehensive set of unit tests and documentation then you could do that - but they didn't. > even codes from a complete idiot If I was wrong, there wouldn't be anything wrong with global variables or goto statements - any code that "works" would be isomorphic to any other code that "works".
- Existenceblinks 4y ago
  > identifies as needed That's how it works even with the same guys on projects. If you think it would break (no tests found), write the tests first. I don't believe someone would write a complete mess million line of codes that works without some tests and docs, that would make him kinda genius. And global vars and goto is not hard to figure out, it's hairy for sure.
- mike_hock 4y ago
  > If they [...] left a good comprehensive set of unit tests and documentation then you could do that - but they didn't. Then you can start by writing the tests. That forces you to dig until you actually understand what's going on.
  - BurningFrog 4y ago
    This can be a lot of fun! My "trick" is to write black box test without understanding the code. Like this: 1. Send in some data 2. Observe what data comes out. 3. Make a test asserting that! 4. Go back to 1.

commandlinefan 4y ago

> be figured out by experienced people Sure, you can figure out how to change it to do some very specific thing that somebody identifies as needed. What you probably can't do (at least not in any reasonable amount of time) is figure out all the things you're going to break in making this change. If they followed good software development practices, left a good comprehensive set of unit tests and documentation then you could do that - but they didn't. > even codes from a complete idiot If I was wrong, there wouldn't be anything wrong with global variables or goto statements - any code that "works" would be isomorphic to any other code that "works".

Existenceblinks 4y ago
> identifies as needed That's how it works even with the same guys on projects. If you think it would break (no tests found), write the tests first. I don't believe someone would write a complete mess million line of codes that works without some tests and docs, that would make him kinda genius. And global vars and goto is not hard to figure out, it's hairy for sure.
mike_hock 4y ago
> If they [...] left a good comprehensive set of unit tests and documentation then you could do that - but they didn't. Then you can start by writing the tests. That forces you to dig until you actually understand what's going on.
- BurningFrog 4y ago
  This can be a lot of fun! My "trick" is to write black box test without understanding the code. Like this: 1. Send in some data 2. Observe what data comes out. 3. Make a test asserting that! 4. Go back to 1.