161–170 of 300 posts
edit: I'm being a little snarky here, but the assumptions here are just too much. This is all best-case scenario stuff that doesn't translate very well to the vast majority of situations it's ostensibly aimed at.
Earlier quoted context omitted.
Hehe. If you can't imagine that then you have a sheltered and probably very happy life. I don't care if it speaks ethernet, arcnet, twinax, X.25 or nothing at all, we'll find a way. By the time you can start sending UDP packets you are already on very solid footing. Be happy if your dev environment does not include an emulated version of the real hardware that mysteriously does not seem to be 100% representative of t…
Telling someone they lead a sheltered life isn't the same as actually answering the question. What actual systems have you worked on that were connected to a database, but couldn't send UDP?
Anything on mainframes or older systems that do not have ethernet.
Anything running Netware or equivalent (true, there you could probably hack some kind of interface but whether it would be reliable or not is another matter).
Earlier quoted context omitted.
> In retrospect it would've been much faster to just rewrite Knockout from scratch. That's most likely not true, but looking backwards it often feels that way. The problem is that you're now a lot wiser about that codebase than you were at the beginning and if you had done that rewrite there could have easily been fatalities. But of course it feels as if the rewrite would be faster and cleaner. How bad could it be, r…
> The problem is that you're now a lot wiser about that codebase than you were at the beginning That may not be true in this case, if the rewriter is also the original author and has remained active in the codebase over the years.
Even so, there is the Netscape story as evidence to the contrary.
Sound advice. re: Write Your Tests I've never been successful with this. Sure, write (backfill) as many tests as you can. But the legacy stuff I've adopted / resurrected have been complete unknowns. My go-to strategy has been blackbox (comparison) testing. Capture as much input & output as I can. Then use automation to diff output. I wouldn't bother to write unit tests etc for code that is likely to be culled, replac…
> re: Write Your Tests, I've never been successful with this ... I wouldn't bother to write unit tests etc for code that is likely to be culled, replaced. I think you misread the author. He says "Before you make any changes at all write as many end-to-end and integration tests as you can." (emphasis mine) > My go-to strategy has been blackbox (comparison) testing. Capture as much input & output as I can. Then use aut…
You capture the initial output from the original code, then treat this canonical version as the expected result until something changes.
Sound advice. re: Write Your Tests I've never been successful with this. Sure, write (backfill) as many tests as you can. But the legacy stuff I've adopted / resurrected have been complete unknowns. My go-to strategy has been blackbox (comparison) testing. Capture as much input & output as I can. Then use automation to diff output. I wouldn't bother to write unit tests etc for code that is likely to be culled, replac…
From my point of view, this is always key. The moment you can have testable components, it's the moment you can begin to decompose the old system in parts. Once you begin with decomposition, Its easier first to pick on low hanging fruits to show that you are advancing and then transitioning to the dificult parts.
pd: I've been all my carreer maintaining & refactoring others code. I've never had any problem to take orphan systems or refactor old ones, and I kind of enjoy it.
If you have such of that old & horrible legacy systems, send it my way :D.
Great advice. Writing integration tests or unit tests around existing functionality is extremely important but unfortunately might not always be feasible given the time, budget, or complexity of the code base. I just completed a new feature for an existing and complex code base but was given the time to write an extensive set of end-to-end integration tests covering most scenarios before starting my coding. This prov…
> Writing integration tests or unit tests around existing functionality is extremely important but unfortunately might not always be feasible given the time, budget, or complexity of the code base. Bottom line: If the project cannot afford to properly maintain the code, it's a failure of the business model. Projects can be maintained indefinitely, but it costs money. And that means the project has to bring in enough…
Earlier quoted context omitted.
I think you just captured the essence of why micro services are so popular. Dynamic languages just don't scale to large codebases, so there's enormous pressure to decompose software into chunks that can be digested more easily. Some amount of this is good, but it often forces the chunk boundaries to be smaller than the "natural" clumping of data and behavior in a distributed system. IMHO this is a much worse problem…
"hundreds of microservices" I can't imagine a scenario where you need hundreds although I don't doubt that people will create such a system.
> Yes, but all this will take too much time! I'm actually quite curious; how long does this process typically take you? What are the most relevant factors on which it scales? Messiness of existing code? Number of modules/LOC? Existing test coverage?
How long it takes depends on the mandate given by management. Sometimes it's 30 days to get from zero to something stable and incrementally improvable at which point we hand back to the company with maybe a transition period where we still manage the project. Sometimes it is just a feasibility study in which case it can be even shorter. But if it is boots-in-the-mud (which is where the real money is) then it can be up to a year.
It scales just fine provided you have the people and this is more often than not a huge problem. It's happened that we had to leave people in place for months or even years after the project was in essence done simply because as soon as our backs were turned it was back to the usual methods. That's actually really frustrating when it happens.
Existing test coverage can speed things up but if the tests are brittle or otherwise not helpful can actually make things much worse.
As for number of modules or LOC: if you're doing a platform switch that can really eat up time, if it is just to bring things under control then it does not really matter much.
One you did not mention, but which can greatly impact the speed with which you can move is the quality of existing documentation. If there is anything at all, especially up to date requirements documentation that can serve as a tie breaker between a suspected bug or a feature it can make a huge difference.
How does one get better if they only ever work in code bases that are steaming piles of manure? So far I've worked at two places and the code bases have been in this state to an extreme. I feel like I've been in this mode since the very beginning of my career and am worried that my skill growth has been negatively impacted by this. I work on my own side projects, read lots of other people's code on github and am alwa…
I generally clear my head by reading mailinglists and looking at how projects of my interests do things and keep their commits in order, especially around bugfixes. OpenBSD is a fun one to read through as well as others. I also go to/watch talks about people managing their own piles of manure and change processes. As long as you keep your eyes open to other people doing what your organization is struggling with right…