8 ms·
7 or 8 years ago I had to take over a Java project on the order of ~10k lines. I reduced the code size by 77% by rewriting it in, wait for it...Java.
by mightybyte 11y ago
7 or 8 years ago I had to take over a Java project on the order of ~10k lines. I reduced the code size by 77% by rewriting it in, wait for it...Java.
- gnarbarian 11y agoHindsight is 20-20. The iterative bloat during development can happen for so many reasons. (Numerous changes in requirements late in the project, many developers working on numerous modules, design for flexibility and expansion that are never used, going too far down a path that turns out to be more work than an alternative). Once a program has been in production for a while and its use cases are more well defined it becomes easier for a single person to swoop in and rewrite it in a far more conscice way. In most of these cases I think the language is pretty irrelevant in terms of how much can be culled.
- deleted 11y ago[deleted]
- alch- 11y agoCall me a starry-eyed idealist, but > The iterative bloat during development can happen for so many reasons. (Numerous changes in requirements late in the project, ... and people not cleaning their mess up afterwards; > many developers working on numerous modules, ... without proper coordination, or, without the drive to keep things clean (i.e. proper manners); > design for flexibility and expansion that are never used, ... and never cleaned up, i.e. left there to rot by the people who put them there; > going too far down a path that turns out to be more work than an alternative) ... and not cleaning up. > Once a program has been in production for a while and its use cases are more well defined it becomes easier for a single person to swoop in and rewrite it in a far more conscice way. I think it's always easier for the guy/gal who wrote something to clean it up than for the next guy/gal, who doesn't know the code or its history as well. Really, this is all just people not cleaning up (or being allowed to clean up) after themselves. Now if we could all just be nice to each other and hold hands..
- gnarbarian 11y agoComing from a 10 year veteren in consulting for orgs ranging in size from 3 people to federal departments. Most of the time there isn't any budget left after they have a functional app for cleaning things up. Despite impassioned hand wringing the client will place value on things they can see over things they can't. So any budget left over will almost invariably be directed toward additional features and not on proper engineering. Sad but true. Speaking to your points there's also the problem of not being able to see the forest through the trees for developers who have been with a project from the beginning. So large refactoring endeavors can be less obvious to them. They may also have fatigue and be less willing to rewrite everything. This combined with budget pressure is all it takes for the bloat to stick.
- marcus_holmes 11y agoThe point and purpose of commercial programming is profit, not beautiful code. Yes, I know, tech debt is a thing and those that don't pay attention to the engineers will soon find themselves with a shitty code base that they can't sell. It can be really, really hard to persuade a management board that you need to take a bunch of their expensive techs to not write new features that will improve saleability, but instead rewrite the code-base (that they're still depreciating), for no net gain (and considerable risk) except to maybe reduce the support overhead and make future developments easier and cheaper.
- Joeri 11y agoAfter my own decade of enterprise programming i can there only two ways to obtain clean code. Either you build it right from the start, or you make a cleanup a blocking requirement before a high value feature can be added (which often requires a liberal interpretation of the word 'blocking'). I'm a fan of the first approach. Building it right is the most efficient way to build, with the overall lowest amount of effort required. It doesn't mean gold-plating, rather the opposite: keeping things light, elegant and minimal. Anything that can't be built cleanly isn't built at all (yet), or at the very worst it is mocked with a fixed data implementation, which suffices for demos but not for shipping. However, the problem with building it right is that you have to learn all the wrong ways to build before you learn how to stick to the narrow path of clean code. I wish we could do brain dumps from old hands to young wolves and not see the same mistakes repeated by every generation of programmers.
- mrweasel 11y ago>Hindsight is 20-20. The iterative bloat during development can happen for so many reasons. Indeed, I once had the pleasure of replacing a BizTalk server with 50 lines of C#. It wasn't that the BizTalk server wasn't a bad idea. The project was for a big harbour, which have documents, cargo manifests, import papers and a ton of other stuff flying back and forth. The idea of having a central hub for data exchange and data conversion wasn't actually that fare fetched. It's just that the only part that was ever implemented was a the upload of a small 5-10 line xml file to the maritime administration, regarding the departure of ships. After three years of running a BizTalk server, for that one purpose, and with no-one fully understanding Biztalk, we just replaced it with a custom Windows service. If anything the takeaway is that you projects should be revisited once in a while for clean up.
- gnarbarian 11y agoThis is a perfect example of what I'm talking about. People can get caught up in the process including all sorts of possible use cases and lose sight of what really matters. After the dust settles you can see what it's actually used for. And sure, its not like the other use cases were bad or wrong, its just not how it ended up. It's possible that the other use cases never got traction because of some longest yard effort required on the client's end to implement a workflow. But even that low of a bar ended up being too high.
- userbinator 11y agoJava is quite a bit more verbose than some other languages, but I think the culture is a significant factor; C# is similar. I've noticed the tendency to overabstract and overgeneralise, apply design patterns for the sake of using them, etc. is particularly strong. It's inexplicably hard to trace out the train of thought that makes things like this appear: https://news.ycombinator.com/item?id=4549544 https://news.ycombinator.com/item?id=4549544 I've written small Java apps --- one class only, i.e. one source file --- which needn't be any more complex, yet coworkers have said there's something uncomfortable about my code; but for some reason can't explain exactly why. I'd get comments like "wouldn't it be better if you made this (only used once and very trivial) line of code a separate function?" "could you use more classes?" (for a <100LoC script-ish thing that had almost no duplicated code nor much in the way of loops.) It's almost as if they can't get their heads around how simple something can be, so it somehow feels very wrong to them. Then there's the extremist "premature optimisation is evil" attitude, which I think is completely misguided because more code and complexity is bad not only in terms of computer time but also programmer time --- it takes more time for programmers to design, write, read, and debug more complex code.
- delecti 11y agoI've gotten many code review comments to the effect of "can you break this out into an interface?" so I 100% understand what you're saying. Many of the instances were things that we were only likely to make one example of either. I could see that argument being valid if there was a clear second implementation in mind, but an interface with only one implementing class is often just wasted time.