Code Cleanup Culls LibreOffice Cruft 317
mikejuk writes with an interesting look at what coders can get around to after a few years of creating a free office suite: dealing with many thousands of lines of deprecated code: "Thanks to the efforts of its volunteer taskforce, over half the unused code in LibreOffice has been removed over the past six months. It's good to see this clean-up operation but it does raise questions about the amount of dead code lurking out there in the wild. The scale of the dead code in LibreOffice is shocking, and it probably isn't because the code base is especially bad. Can you imagine this in any other engineering discipline? Oh yes, we built the bridge but there are a few hundred unnecessary iron girders that we forgot to remove... Oh yes, we implemented the new chip but that area over there is just a few thousand transistors we no longer use... and so on." Well, that last one doesn't sound too surprising at all. Exciting to think that LibreOffice (which has worked well for me over the past several years, including under the OpenOffice.org name) has quite so much room for improvement.
Not at all. I've had a house built. (Score:5, Interesting)
There are probably dozens of extra nails that were just hammered in rather than be removed. There are extraneous pieces of lumber.
And a house that was remodeled? I've seen newspaper used as filler. I've seen layers of roofing, with things buried in between layers.
Frankly I don't know what's inside my walls, and I'm not sure I want to know.
oooh yes (Score:4, Interesting)
I've been working on a project where there were 3 separate wrappers around a database, each returning different objects containing the same data... So you had to convert those each time two modules using different wrappers needed to communicate. I tried to clean it up a bit, but eventually I stopped because my manager was frowning upon that because "I broke working code". Also there were parts that I didn't know if they were still in use. I also ran a profiler and found 80% of the functions never got called. That doesn't mean it's dead code of course, but looking at the function names I got an eerie feeling with a bunch of them. Anyway, I learned a lot about how not to manage software, I quit the company since then and I can only hope things have changed over there.
Re:I'd bet there is. (Score:5, Interesting)
I'm mostly surprised that they're still getting performance improvements. It seems like they've done more over the last year than Sun did during the entire time it owned the project to unbloat it.
Cruft in engineering... (Score:5, Interesting)
Oh yes, we built the bridge but there are a few hundred unnecessary iron girders that we forgot to remove...
Well, look at bridges built in the 1800's compared to the ones today. Would we build a modern bridge today using wrought iron links http://en.wikipedia.org/wiki/Clifton_Suspension_Bridge [wikipedia.org]? Each building made in a certain period in a way represents a degree of refinement compared to its predecessors. Better materials, better methods. Buildings in general cannot be "cleaned up" the way code can, where "cruft" today was yesterday's conservative design.
Read a book about the differences in the construction of the World Trade Centers versus the Empire State Building, for example (the WTC has sibling buildings still around using the same techniques, such as the Aon [nee Amoco] Building in Chicago)...
Re:Bad examples (Score:4, Interesting)
...subsystems replaced in boards by new designers not confident enough to remove the old design, etc.
It sounds crazy, but I work with a real-life example, a beamforming [wikipedia.org] circuit board that utilizes a certain technique, but has all the legacy components utilizing another technique that was never even implemented!
In that case, it wasn't a matter of confidence, but probably corporate sloth - engineers are expensive, and so they figure that paying the board-house more for the extra components per board would be cheaper than getting an engineer to redesign the board.
This happens in other disciplines. (Score:5, Interesting)
The quoted section in the summary asks if we could imagine this in other engineering disciplines. As the rest of the summary points out, it happens all the time in microchips. It also happens a lot in civil engineering, including bridge building. Removing things takes work. Unless there's work to be saved by doing it, or some way to profit from selling what's removed as scrap or it's a safety issue to leave it most engineers won't remove old parts of a structure. Consider underground pipes. How often are they removed when they're replaced? If the new ones are being laid down where the old ones went, they'll be replaced. Otherwise, 90% of the time they'll just leave the old ones there. Same goes for just about everything. Old installations of any kind are full of stuff that no longer serves any purpose. Brackets and supports for heavy equipment that isn't used anymore, old wiring and panels, concrete slabs that something mystery object used to sit on, etc. When was the last time you saw anyone take away some 30 ton piece of equipment then pay more money to have the floor where it used to sit un-reinforced? Now, sometimes they do. Usually it's when the place is being sold and the new owners are re-modelling. Other times the owners do decide to do a major cleanup. That's exactly what's being done here with libreoffice. Makes it no different than any other engineering discipline then.
Incidentally, if it's truly "dead" code, then it shouldn't actually be compiled, so it's not like the bridge engineer left in a bunch of extra girders, it's more like he's keeping addendum 6-c to revision 12b of the plans for section 3 in the same file cabinet as revision 13 rather than shifting it to a storage box and warehousing it.
Not to mention the human genome itself. (Score:5, Interesting)
Human DNA (and just about every other species as well) is full of things like inactive duplicate genes (some with slight alterations), pieces of old retroviruses, and other mutations and replication errors that have been "commented out". Plus a whole lot of sequences which we don't know what they're good for yet.
Re:Worked Well? (Score:1, Interesting)
Re:This happens in other disciplines. (Score:5, Interesting)
A nice engineering example is the stone pylons at each end of the Sydney Harbour Bridge. They were built to support the cranes that were used in constructing the steel arch of the bridge. Since the bridge's completion they've served no structural purpose whatsover.
As the parent poster suggests, it would have cost time and money to remove them. However, in bridge building they plan around that - a bit of extra effort was put in at the start and the pylons were designed and built in such a way that they looked good after the bridge was finished. They were left in place as a feature of the completed structure and, as they were built in sandstone, they do a reasonably good job of making the bridge work visually with the feel of the historic precint beneath the southern end of it.
Dead code rarely adds anything to the aesthetics of software.
80286 microcode (Score:2, Interesting)
Intel's microcode to support 16-bit protected mode became obsolete as soon as the 80386 was released, but they had to support it for backward compatibility, in case someone tried to install Windows 3.0 on an IBM AT clone, for instance. Probably that microcode has been carried forward ever since. Also, there are a lot of CISC instructions such as SCAS* with the "REP" prefix which were heavily used in assembly language in the eighties, but which are now deprecated and typically slower than the RISC-style replacements.
Re:oooh yes (Score:5, Interesting)
Well, it was an embedded company. This was the first project of such a large scale, and they lacked experience. The manager had worked there for 30 years, and had an electrical engineering background. So it wasn't an ideal situation: he was certainly competent and he could definitely write code, but lacked the experience in software engineering, like how to keep a large software base maintainable. So for example, he had this obsession with not changing code once it was tested. Since all these modules were tested, he was very nervous about changing it. What he failed to see, though, was that more modules were going to be added, and without a clean definition of how this data was to be represented, constant conversions were going to be needed (plus some other things I'm not going into now). Also, automated testing was not a practice there. This is one of the things I worked on introducing at the company, although frankly it was much to late to add it to the existing project. So he was never going to allow to merge the changes back in, because it "broke" tested code.
And I'm not saying I'm all for changing tested code - not at all , but in some circumstances, spending some effort up front can save you a lot of time later on. And I'm sure it would have.
Also, I'm quite confident of my skills. Sure I can still improve, but I surely developed a reputation of writing code that "just works". After 4 years, only a small fraction of the bugs were assigned to me, mostly they were located in parts I didn't write. Mastering the programming language is important, but there are lots of other very important things that matter. You just need a lot of discipline, checking all input, immediately failing when something goes wrong (not letting bad data trickle down the code), clean separations, higher order programming, trying to minimise the interface between modules etc... The list is so large, it becomes more of an intuition.
I hope this clarifies it a bit, I surely wasn't expecting the Spanish Inquisition.
Re:Automate it (Score:3, Interesting)
Do it constantly, even in the details like method names, and your code will have better quality and will be easier to understand.
Modern IDEs will resolve the tedious parts, you just have to think of the change, and the tool will do it.
The book Refactoring: Improving the Design of Existing Code is an essential resource.
Comment removed (Score:4, Interesting)
Re:I'd bet there is. (Score:3, Interesting)
I don't think they are talking about unused mutators. If anything Object Oriented programming makes it much easier to find and get rid of unused code BECAUSE of the data protection it implies. Having the code segmented and modular in different classes would make it worlds easier to find and remove dead code at all stages of development.
But really, C, with their fancy "structs" and "flow control" just leads to unnecessary cruft, we should just stick with ASM and Goto, b/c that's way more maintainable ;)
Re:Bad examples (Score:4, Interesting)
I think it's pretty common, and not just with test logic like scan chains. I've worked on numerous ICs where some later project wants to reuse a part of the design, without necessarily using everything. If time and budget allow the unused bits get removed and a smaller design results, but more often the unused logic is tied off (at the board level or via metal mask - board level being cheapest and metal mask being cheaper than cutting a new set of diffusion masks for a potentially small runner) and the same die and package are reused (this may allow test fixture reuse also).
I've seen some pretty egregious cases of this however. I recall opening up a 4-port USB hub once (the cheap $10 ones) only to find a gigantic controller chip on it (something like 80 pins) of which about 10 pins were connected. It was obvious the chip didn't start life as a USB controller, but apparently it was cheap enough to throw down as-is. I always wondered what else was on the chip, perhaps part of something that normally has an embedded USB hub (monitor or keyboard maybe).
Re:It doesn't matter (Score:3, Interesting)
Re:I'd bet there is. (Score:4, Interesting)
Just to be Snarky, I'll point out that the Glasgow Haskell Compiler politely informs me whenever it finds a dead function. Functional languages are light years ahead of anything else when it comes to the Compiler actually being able to reason about the code it's compiling.
Re:Not at all. I've had a house built. (Score:3, Interesting)
Building a house isn't a one-time endeavor. Much like code, houses are never 100% finished. They're frequently repaired and less frequently remodeled, renovated, or expanded. If you look at photographs of the same house over the span of a century or more, it's sometimes hard to believe that the final version is the same building as the original. And when people work on their houses, they usually go for the most cost effective approach, even if that means leaving no longer used stuff in place because it would be more expensive to rip it out. Look inside the wall of an old house, and you'll be amazed at the stuff you find.
Re:Not at all. I've had a house built. (Score:4, Interesting)
That's nothing. Whoever built the wall that exists between my office and the dining room left inside a leather dog collar and a half-dozen pork (I think) rib bones.
We've also found a cast iron floor lamp inside of a wall, as well as several hundred copies of the Saturday Evening Post that are positively impossible to drill through.
Pez dispensers seem so...basic.
Re:Automate it (Score:4, Interesting)
Yeah but they don't help much. The compiler will kill off any code that really isn't used so to make noticable performance imporvements you have to do stuff at the achitectural level. Maybe someone wrote a function but then later there were performance issues and it was replaced in some code but not elsewhere. Now you have two functions doing the same thing but the compiler and automated tools can't really tell that. The other classic one is where you have features that are no longer used or no longer make sense but are still possible to invoke, and again you need to work at the architectural level for that stuff.
Re:Not at all. I've had a house built. (Score:3, Interesting)
Good analogy.
But Libreoffice still uses Java. I don't see that fitting into your analogy, because the Java dependency really has to be removed. It was put there only because OpenOffice was in the hands of Sun. Now Java is in the hands of Oracle. The Java dependency has to go.
Re:This happens in other disciplines. (Score:4, Interesting)
We are currently preparing to move to another office building in another town.
Our old premises are just like you describe. Build in 1964.
Not counting anything else: There is 600 kilometer of Cat5e cabling in the building-complex. (I was involved in the Coax -> Cat5e upgrade back in '97. Still remember some details.)
Actually it is a good thing.
The recycle value of the wiring is more than the value of the building and the grounds.
With todays fucked up real-estate market for office buildings we couldn't sell the old location to anybody.
But because of the recycle value we had no trouble selling the entire site to a demolition company.
Win-win for everybody:
We get money for what is basically an unsellable building-complex.
They will break it down and recycle it. Gives them about a year of guaranteed work and a reasonable profit when due to the recession their business is at an all time low.
Afterwards they will sell the cleared grounds to the City Councel who are desperate to get a reasonably priced area of land at the edge of the city-center by 2014 so they can build a new City hospital. (The current hospital is on land not owned by the City, The contracts end in 2016 and can not be renewed because that would require a re-check of the environmental status of the grounds and everybody knows there is pollution there. That's wasn't an issue in 1986 when the old hospital was build, but new legislation passed in 2008 making it an issue now.)
Re:This happens in other disciplines. (Score:2, Interesting)
Interesting story, but Wikipedia suggests otherwise (http://en.wikipedia.org/wiki/Sydney_Harbour_Bridge). That article indicates that the cranes actually were supported by the arch itself, and that the pylons were only added after the fact: "They were included to provide a frame for the arch panels and to give better visual balance to the bridge. The pylons were not part of the original design, and were only added to allay public concern about the structural integrity of the bridge." The arch and deck were finished in June 1931, and the pylons weren't even started until July of that year.