4 ms·

It is not that simple and comes back to the same old maxim - as long as the only documentation of what the system is doing and why is its source code, you are d

It is not that simple and comes back to the same old maxim - as long as the only documentation of what the system is doing and why is its source code, you are doomed. If you have a written detailed guidelines of what you are doing and why, which design decisions were made and why, which data representation is used and why and what corresponding algorithms are and why, then one could re-write parts of the system in different languages/frameworks just for fun or to explore and compare. Coding or rewriting is second to deep, hierarchical understanding of hows and whys. This is how the most of programming exercises are designed - once you have understood how it should be, which results each procedure should return (wishful thinking and tests before code, to define domain and range of a procedure - ideas as old as SICP) then coding is the most trivial part. Look at antirez - he is a rare example of a guy of deep understanding before code.

antonpirker 12y ago
'once you have understood how it should be, which results each procedure should return then coding is the most trivial part.' I wholeheartedly agree with this! The big challenge is that you have the patience (and the patience of the management) to understand the old system thoroughly before starting to write new code.
thirdtruck 12y ago
Uncle Bob made this point very salient in one of his videos: If there was some catastrophic, quirky failure of backup, and you could only save either (a) all your production code, sans test, or (b) only your tests, which would you rather save? Assuming you've written thorough tests, they win out over code every time. The tests remove all ambiguity. I'm reminded of a story that illustrates the point: A young woman always cuts the ends off of her pot roasts before cooking them, following her mother's example. One day, she asks her mother why they do that. The mother doesn't recall, so she asks the grandmother. The grandmother looks at them both, shrugs, and says, "When I was your age, we lived in an apartment with a very small oven. We had to cut the pot roast down to make it fit!"
- rquirk 12y ago
  Oh come on! Reality check please :) Tests alone provide little value to anyone. At least if you had the production code you could keep it running in its current state while you added back those important tests bit by bit. Most of the tests wouldn't be needed as good code tends to be churn-free. Finally if you wrote the code TDD style, then writing tests for even the hairy bits would be "easy" compared to rewriting the whole system.
  - thirdtruck 12y ago
    I'm going to have to respectfully disagree. :) (Or, with apologies to Adam Savage, "I reject your reality check and substitute my own!") A huge portion of my day-to-day agony at my current job stems from a lack of tests. The developers on my team (all lifelong employees, where I'm a contract hire) are terrified of making more than the absolutely necessary changes to code. I can't replace literally copy-pasted code with a shared method without push-back. To even speak of refactoring is verboten, at least in front of our internal customers. Testing small changes can take days, as it must go through QA and the customer, and surprising bugs still slip through. As someone who went through Fowler's Refactoring as bedside reading, this process and turnover rates drives me batty. Here's the thing: We have the production code up and running, and I'm already adding tests where I can, but we constantly run into implicit requirements. Even the senior developer, who's worked on this code base for years, keeps discovering things about it. We continue to discover genuine bugs, too. The production code empirically lacks enough information to reproduce the tests. And "good code" begs the question. In fact, it begs two questions: (a) How do you know code is "good" if it isn't tested empirically, and (b) how can code ever be churn-free when the requirements themselves keep changing?
    - rquirk 12y ago
      Heh, that agony description was eerily familiar, and I'd be the employee! The hard part is not being afraid to make an obviously right change, even if it means spending ages manually testing things and then continuing to follow up weeks later when the non-obvious things you didn't think of break :) Even in the face of changing requirements I've found that there are substrates of code that do their job without (showing?) major bugs for years. They never needing fixing. That's your good code. If you had unit tests, you'd never run them anyway because you never touch that code. They are the "select()"s of this world, but specific to whatever you're writing. Now if the whole system had to be rewritten, the old tests would be useless anyway. You mention requirements that have changed, so those tests you had would no longer apply. You'd have to write a new system and new tests ;-) FWIW I've found that peer code review and static analysis tools give you a lot of what unit tests would anyway, without the overhead of having to write the tests and update the dead code when you rewrite the affected part of the system. I mean... what's the point of code anyway? Is it to be "perfect"? Or is it to do a job, earn you money, and be more or less maintainable? Constantly refactoring to stay in the same place is worse than copy-pasting code, from a business owner's POV. Sometimes it is better to have 2 copy pasted methods that are deployed and the customers are happy, than trying to have 1 perfect method sat in development. If those 2 methods never need updating again, you wasted time refactoring. If you would need a third copied method later on, that's the time to refactor. Maybe I'm being a bit devil's advocatey. Unit tests and refactoring are good tools, but they are not "free" (since you have to test the real system anyway at some point) and Uncle Bob is a bit of a snake oil salesman anyway :-P
xorcist 12y ago
Doomed is a bit harsh perhaps. Documentation, even if it exists, is never perfect. I don't think you can completely get away without some study of the old code base. A good rule of thumb is that reading code takes at least as long time as writing code.
- dschiptsov 12y ago
  There are two observations. One, very general, is that the best writing is re-writing. It is mostly about scientific writings, when your understanding grew and clarified since the first writing. The second one is "the second system effect" from Mythical Manmonth, which says that when people re-design a system (or a language) they tend to make a kitchen sink from it, throwing in everything that comes to their minds (hello, Rust?) There is also a common sense notion that a sequel for the sake of a new version is usually much worse than the original. What is common of them all? It seems that still the best writing is rewriting, but only if your understanding of the details has been grown and now you have less clutter in your mind. But if you do a rewrite without much thinking or just to get shit done, there is a high probability that you will fail.
Joeri 12y ago
I've done the big rewrite a few times, and what I've learned from it is that a system so "bad" that it is in need of a rewrite does not have a caretaker who understands it well enough to provide perfect documentation of choices made and reasoning behind them. In fact, a system that bad typically has plenty of choices which were made for no good reason at all. So, you never go into the big rewrite with perfect documentation or good tests, because if you had those you wouldn't need a big rewrite.

antonpirker 12y ago

'once you have understood how it should be, which results each procedure should return then coding is the most trivial part.' I wholeheartedly agree with this! The big challenge is that you have the patience (and the patience of the management) to understand the old system thoroughly before starting to write new code.

thirdtruck 12y ago

Uncle Bob made this point very salient in one of his videos: If there was some catastrophic, quirky failure of backup, and you could only save either (a) all your production code, sans test, or (b) only your tests, which would you rather save? Assuming you've written thorough tests, they win out over code every time. The tests remove all ambiguity. I'm reminded of a story that illustrates the point: A young woman always cuts the ends off of her pot roasts before cooking them, following her mother's example. One day, she asks her mother why they do that. The mother doesn't recall, so she asks the grandmother. The grandmother looks at them both, shrugs, and says, "When I was your age, we lived in an apartment with a very small oven. We had to cut the pot roast down to make it fit!"

rquirk 12y ago
Oh come on! Reality check please :) Tests alone provide little value to anyone. At least if you had the production code you could keep it running in its current state while you added back those important tests bit by bit. Most of the tests wouldn't be needed as good code tends to be churn-free. Finally if you wrote the code TDD style, then writing tests for even the hairy bits would be "easy" compared to rewriting the whole system.
- thirdtruck 12y ago
  I'm going to have to respectfully disagree. :) (Or, with apologies to Adam Savage, "I reject your reality check and substitute my own!") A huge portion of my day-to-day agony at my current job stems from a lack of tests. The developers on my team (all lifelong employees, where I'm a contract hire) are terrified of making more than the absolutely necessary changes to code. I can't replace literally copy-pasted code with a shared method without push-back. To even speak of refactoring is verboten, at least in front of our internal customers. Testing small changes can take days, as it must go through QA and the customer, and surprising bugs still slip through. As someone who went through Fowler's Refactoring as bedside reading, this process and turnover rates drives me batty. Here's the thing: We have the production code up and running, and I'm already adding tests where I can, but we constantly run into implicit requirements. Even the senior developer, who's worked on this code base for years, keeps discovering things about it. We continue to discover genuine bugs, too. The production code empirically lacks enough information to reproduce the tests. And "good code" begs the question. In fact, it begs two questions: (a) How do you know code is "good" if it isn't tested empirically, and (b) how can code ever be churn-free when the requirements themselves keep changing?
  - rquirk 12y ago
    Heh, that agony description was eerily familiar, and I'd be the employee! The hard part is not being afraid to make an obviously right change, even if it means spending ages manually testing things and then continuing to follow up weeks later when the non-obvious things you didn't think of break :) Even in the face of changing requirements I've found that there are substrates of code that do their job without (showing?) major bugs for years. They never needing fixing. That's your good code. If you had unit tests, you'd never run them anyway because you never touch that code. They are the "select()"s of this world, but specific to whatever you're writing. Now if the whole system had to be rewritten, the old tests would be useless anyway. You mention requirements that have changed, so those tests you had would no longer apply. You'd have to write a new system and new tests ;-) FWIW I've found that peer code review and static analysis tools give you a lot of what unit tests would anyway, without the overhead of having to write the tests and update the dead code when you rewrite the affected part of the system. I mean... what's the point of code anyway? Is it to be "perfect"? Or is it to do a job, earn you money, and be more or less maintainable? Constantly refactoring to stay in the same place is worse than copy-pasting code, from a business owner's POV. Sometimes it is better to have 2 copy pasted methods that are deployed and the customers are happy, than trying to have 1 perfect method sat in development. If those 2 methods never need updating again, you wasted time refactoring. If you would need a third copied method later on, that's the time to refactor. Maybe I'm being a bit devil's advocatey. Unit tests and refactoring are good tools, but they are not "free" (since you have to test the real system anyway at some point) and Uncle Bob is a bit of a snake oil salesman anyway :-P

xorcist 12y ago

Doomed is a bit harsh perhaps. Documentation, even if it exists, is never perfect. I don't think you can completely get away without some study of the old code base. A good rule of thumb is that reading code takes at least as long time as writing code.

dschiptsov 12y ago
There are two observations. One, very general, is that the best writing is re-writing. It is mostly about scientific writings, when your understanding grew and clarified since the first writing. The second one is "the second system effect" from Mythical Manmonth, which says that when people re-design a system (or a language) they tend to make a kitchen sink from it, throwing in everything that comes to their minds (hello, Rust?) There is also a common sense notion that a sequel for the sake of a new version is usually much worse than the original. What is common of them all? It seems that still the best writing is rewriting, but only if your understanding of the details has been grown and now you have less clutter in your mind. But if you do a rewrite without much thinking or just to get shit done, there is a high probability that you will fail.

Joeri 12y ago

I've done the big rewrite a few times, and what I've learned from it is that a system so "bad" that it is in need of a rewrite does not have a caretaker who understands it well enough to provide perfect documentation of choices made and reasoning behind them. In fact, a system that bad typically has plenty of choices which were made for no good reason at all. So, you never go into the big rewrite with perfect documentation or good tests, because if you had those you wouldn't need a big rewrite.