
LibreOffice: cleaning and re-factoring a giant code-base [video] - ExpiredLink
https://fosdem.org/2013/schedule/event/challenges_libreoffice/
======
raverbashing
"Come and hear how we’ve built an international team of developers to tackle
the problems of resurrecting a poorly-understood, gigantic code-base
extensively commented in German, with no unit tests, a tangled build
infrastructure, and twenty-five years of un-paid technical debt."

Looks like a project I worked on. It's eerie how similar it is (and no, it was
not an office app, it was something different).

At least the comments weren't in German, but there were a couple of ones in
Dutch. (Not that the comments were of any help)

No unit tests: CHECK. Twenty-five year of technical debt, CHECK. And now we're
supposed to make it work in a different platform

So thank you, but I don't plan on touching a monolithical piece of old C++
ever again. Not even with gloves.

~~~
jacquesm
It's doable.

Start by adding integration tests, then (try to) identify the core of the
project and isolate that in its own sub-project in the repo. Add unit tests
for the functions in the core and then split the remainder into parts that are
peripheral and that could be removed/disabled. (say a spellchecker). Next up
re-factor the core until you're happy with the state of affairs, but keep the
interface the same. If there was no interface to the rest of the code then
you'll need to define one and implement that as well as changing the
peripheral code to use that interface. Then look at each peripheral piece and
decide if it is worth saving, needs rebuilding or refactor it as well.

The basic trick is to reduce scope until a subsection of the work becomes
tractable.

With a really large project this is a multi-year effort with a team of
seasoned programmers, it's hard and it means that while you do it there will
be no honoring feature requests. You need management buy-in, patience and
perseverance but that goes for any large effort.

Building fresh and green stuff is obviously much more fun to do but taking an
old codebase and making it nice is (to me, at least) just as rewarding.

~~~
kami8845
I find this argument smells of rationalisation to me: You admit yourself that
building new stuff is much more fun. Say making an old codebase is "just as
rewarding" but in order to actually understand all the legacy you need to put
in 2x (or whatever the amount) of work that you'd need to build a new thing.
Wouldn't you want to build 2 new things instead?

I could never imagine someone on their own accord, going by themselves into a
30-year-old codebase and refactoring it, just to make it "look nice". On the
other hand people constantly build new stuff (too much of it really). I think
it would be fine to admit that working on new code is more desirable than
working on old code. Sometimes the latter needs to be done, but I think most
programmers are happy to avoid maintenance work when they can.

~~~
jacquesm
Building something new is more fun in the beginning. Refactoring an old
codebase and making it fly is rewarding when you're done. This is _not_ about
cosmetics.

Both are fun, assuming you stay in long enough the first will at some point
turn into the second, no matter how well your intentions were at the beginning
('this one will be different, this time I'll get it right').

~~~
kami8845
Yeah but programmers are generally not bound to a codebase for life. A friend
of mine who works at Google says that he generally works on projects in the
"do it new and figure out what it needs to do" phase, while there's other
engineers at Google who are very good at the maintenance phase and "keeping
stuff running and adding slowly to it". I think that's a very nice way of
wording it, but I'd definitely want to see myself in the former group, not the
latter.

~~~
jacquesm
> Yeah but programmers are generally not bound to a codebase for life.

If you're young I can see how you might have that impression. But I know quite
a few programmers personally that have been working on the same codebase for
more than a decade, and even a couple that have been working on the same
codebase for 3 decades.

The web is still young enough that most people that came into programming
through building websites have no idea how long most code bases are alive.

There is a neat little proverb here: programs are like children, you can start
one in an evening but you'll end up supporting it for the rest of your life.

~~~
kami8845
Not arguing against the fact that old codebases exist and that people have to
take care of them.

However I don't agree with glorifying old codebases or putting them as "equal"
to working on new stuff. If you're happy doing that, then fine, no one's going
to stop you from doing it, but I do think that in general, given the choice,
almost anyone would pick building something anew over working on a legacy
codebase.

~~~
breck
The neat thing about old codebases, is that even if the code is messy, the
problem it solves can be very interesting.

"Legacy codebase" is another word for "important codebase".

When you're coding, you solve the most important problems first. Thus, in some
sense, the older the code base, the more important the problem it solves.

~~~
ams6110
And sometimes the code is actually quite good (not saying that's the case in
LibreOffice, I have no idea).

~~~
breck
Agreed. I often stumble across some project written in the 80's and think,
"wow, that's so much clearer than my code".

We have a lot more tools than programmers did back then, but tools are
incapable of long term thinking.

------
cpursley
LibreOffice needs some UX/UI volunteers, bad.

~~~
qnk
Not only LibreOffice, this is somewhat a general sentiment I have about most
Open Source Software. If I were a designer I'd love to be part of such an
important project like this.

I don't get why designers are always doing stuff like redesigning website X
for free, without being asked to, but miss great opportunities to be in the
spotlight by participating in projects like GNome, KDE or the likes. There are
many examples of good OSS projects that could use some UX/UI love, one that
comes to mind right now is Moodle, for example.

Is it designers that don't like to participate in OSS? Are programmers making
it harder for them to join these type of projects or is simply the fact that
they don't bring to much excitement or challenge to the design community?

~~~
taligent
>I don't get why designers are always doing stuff like redesigning website X
for free.

Simple.

Because if they did assist with FOSS projects much of the time they would be
dealing with developers who (a) think they know what users want better (b)
have no respect for designers and (c) believe obscure feature X is more
important than UI.

Remember this is the same group of people e.g. on Slashdot/Reddit who think
the iPad is an overpriced toy and think people are sheep for buying it.

~~~
PommeDeTerre
After the GNOME 3 disaster, it's understandable why many developers within the
open source community have become skeptical of designers and their
contributions.

Within a single release cycle, these designers managed to destroy what was
once among the most vibrant of all open source projects. The existing GNOME
users have been alienated by the absolutely horrible UI. Among their ranks
were many good developers and other contributors, too, whose absence now
prevents the project from recovering. A large portion of these users moved on
to KDE or Xfce, rather than MATE, causing further harm to the GNOME project
and community.

There are other cases, too. Windows 8 and the UI changes starting with Firefox
4 are other recent, and major, examples of the work of designers going
terribly wrong. The end result is software that is nearly unusable, or much
less usable than previous versions.

The skepticism you describe is very well earned and deserved.

~~~
takluyver
This neatly illustrates another problem with redesigning popular software: no
matter how much time you spend, no matter how beautiful you make the design,
the people who're already using it are used to its current layout, and don't
care about learning a new interface.

If you could give people a completely fresh, unprejudiced choice between Gnome
2 & 3, Windows 7 & 8, or Firefox 3.5 & 18, I bet many of them would choose the
newer version. I don't think (most of) these UI decisions are objectively bad,
and over the long run they might even pay off. But when the user upgrades and
suddenly can't see how to make it Frobnicate, they get angry.

~~~
xradionut
After you've learned hundreds of interfaces over 3 decades, you learn that
newer can be, but isn't always better. So when I see YAIR, (Yet Another
Interface Redesign), I get a case of deja poo, (I have seen this shit before).

------
Surio
Going through some of the discussions and views and opinions on legacy code
rewrites, I thought I should provide another relevant reading warstory:

An oldie but a goldie:
<http://www.joelonsoftware.com/articles/fog0000000069.html>

_EDIT_ While I was reading the thread, it appears @jodrellblank had also
posted it in the discussion elsewhere in the thread.

------
tomelders
I was talking to a friend about "legacy code" the other day and I realised:
the company that's going to put you out of business won't have any legacy
code.

I think you need to have a really good excuse not to completely rebuild your
product from scratch every now and again. Because if you don't, someone else
will.

~~~
bryanlarsen
OTOH, the greatest asset you have competing against the company that's going
to put you out of business is your legacy code.

Every line in your legacy code is there for a reason. Sometimes the reasons
are bad, but often they're there because of some very valuable lesson you
learned from a customer, a mistake you made that your competitor is also
likely to eventually make. Throwing away your legacy code means that it's
likely you'll make the same mistake again.

~~~
cpressey
Legacy code will also tend to have had many of its bugs ironed out, since it's
been in operation for so long. New code will have a whole new set of coding
errors hidden in it, and you'll have to go through that ironing-out all over
again.

~~~
dhimes
I think this is a crucial point we all overlook in our rush to throw out the
legacy code and 'do it right this time.' We're thinking, 'but we'll have unit
tests so we'll catch the bugs.' But in reality, some get through and they tend
to be a real pain in the ass.

I know this probably means that I don't unit test right. It also obviously
means I don't code right, because I have bugs. The point is, these are facts
of (real) life, and to be successful you have to manage the reality. Often
this means that the best course of action is to stick with the legacy code.

~~~
tomelders
You'll have bugs either way. That's a fact of life, and the vast majority of a
developers time will always be spent debugging.

What legacy code does is inhibit your ability to make the fundamental changes
you need to implement in order to stay competitive. And I'm not saying throw
you code out every other week. And I'm not saying every attempt to rewrite
your product should replace what you already have. But the for all the costs
associated with re-writing your product, they pale into insignificance when
compared to being put out of business.

~~~
cpressey
It should go without saying that fewer bugs is better than more bugs, though.

I'm not saying you should never rewrite a system from scratch. But I do think
it's extremely costly to do so, and that it's extremely difficult to predict
when you'll be driven out of business if you don't. So I don't think it's
usually justifiable.

I'd be very interested if someone could supply an example of a company that
was put out of business because they failed to re-write their product.

~~~
Tyr42
If you already saw a threat, then by the time you finish re-writing it,
wouldn't you be dead?

~~~
dhimes
Depends how well you can see the threat horizon.

------
melling
Are the LibreOffice and OpenOffice teams working completely independently? If
not, it sounds like a lot of redundant effort is going to take place.

~~~
stephen_g
Given their licenses, LibreOffice can incorporate any code written for
OpenOffice into their project, but OpenOffice can't use any of LibreOffice's
code.

------
pestaa
I think all good developers have their connotations and anecdotes for words
like 'poorly-understood', 'gigantic', 'no unit tests', 'tangled build
infrastructure', let alone '25 years of technical debt'.

What I was surprised to see is the word 'resurrect'. As if they wanted to
imply LibreOffice was dead.

~~~
BobbyBonsai
Well, I think many developers know the feeling when working with a codebase
which just feels like riding a dead horse...uphill, both ways, in the
cold...and when you manage to refactor _some_ part it starts to feel like it
gets up on one leg and so on.

------
jfb
I wish this was available written instead of as low-bandwidth video.

------
zandorg
I loaded a self-written novel (about 260 pages) into LibreOffice and went to
Print Preview and it hung.

Loaded it into Office and it worked fine.

~~~
BobbyBonsai
So what?

~~~
zandorg
Obviously, because it simply doesn't work as it should.

------
fiendsan
they just need to focus on speed/performance thats the only thing missing on
openoffice/libreoffice its slow... painfully slow!

~~~
macalicious
It's not the only thing. The UX and UI itself is very 'old-school' and IMO
very outdated. It's like using Windows 3.11 instead of Windows XP, let alone
Windows 7/8.

------
evandrix
link to slides please?

------
largesse
I tried watching the video, but it had no information. Not a drop of code or
an ounce of strategy. It was just a status report.

