ReFRACKtoring

Once in a while one find itself on a task where numerous WTF moments appear. You can imagine such a task?

Yes you can. It’s adding new features to legacy code/database or to a ‘WTF’ code base.

A ‘What the F***’ code base, a collection of lines of code that make you shout WTF more than is healthy. You can usually hardly call it a program. It’s a collection of blunders after blunders. Not testable due to lack of interesting unit tests, thus not refactorable (if that’s even a word) without adding a unit test.

And then comes the day. ‘Hi mister, we’d like feature X, Y, Z added to this application.’  You say, ‘ok’ and come back with a rough estimation after carefully reading the specifications. Architect and Programmers decide: ‘Should take about 4 weeks in optimal man days’, what the client then hears that it will take around 3 months. And so the waterfall started spoiling it’s liquid.

You start off with that old database that needs some additions:

Programmer & Architect: First, they’d wish half of it was a document store instead of a relational model, that when looking deeper into it, isn’t that normalized at all. If they would continue using it, it would even become more polluted and non relational. In choir they say “WTF”.

The decision is hard but easy, and needs to be taken. Throw away that database schema, we have no other choice. If we would extend that we put a huge burden on the future of that application. And so it be done. Sometimes digging a new trench for the water is better than to fortify the old one.

They come up with a good database design, generate some JPA code, and put that in the application. It is only then one notices:

Programmer: “Hey what’s with this legacy entities I’m trying to replace with the new ones?”

The IDE answers: “org.example.Person is used everywhere, from the database layer up to the user interface layer (site, api and jms) while passing through a service layer or something that is trying to resemble a service layer. “

Programmer: “WTF, we just wanted to change the database. Not the UI. But it’s so, so. TIGHTLY COUPLED.”  The programmer almost get’s a burn out from seeing the application code. After 10 years of building up his knowledge to be a real software craftsman. He is thrown into the pit, an arena of code with lots of blood on the walls.

The heroic fight to freedom.

The ‘tightly coupled’ infection is being dealt with as swiftly as possible. With a sharp blade and the help of lombok some intermediate objects are carved. The the user interface does not have to change although all the JPA entities are changed.

The real work still needs to be done. Glueing the front-end back onto the backend.

At first the programmers believes it to be not that hard. But then, noticing the lack of any unit test, he decides that he can’t ever be sure about what’s happening inside the code. More, due to the substantial database changes and feature requests. some logic really has to change.
Thus trying to write some unit tests and alter application logic. But when looking for the existing logic the programmer finds a lot of it is actually in a bunch of JSP files full of <c:if> stuff and <% scriptlets, again ‘WTF’.

At this point the programmer considers, for the better good,  throw away that front end!

So before they even started ‘adding new feature’ they had to start implementing the old features, again. By then, of course, more half of the estimated time had passed.
The architect’s and programmer’s work-life balance tipped over to work and wasn’t balanced at all any more.

Will the new feature project be delivered on time? They are not sure. But what can they do? Proclaiming craftsmanship and delivering total crap?

Yes many would probably just ‘add the new features quick and dirty’ postponing the same refactor story to the next round of new feature requests.
Making it even worse since more features and code was added, more needs to be refactored or thrown away and be recreated.  Shame on them!

That is not what you would want?
It’s pretty easy. If you go to the store to buy a hammer, you don’t want the head to fly off with the first hit. You want a decent hammer, made by a good craftsman.

One needs to remind himself constantly.

‘Look at your code as if you are not yourself. Look at it as if you are the next one who will work on it. And then think, would I want to see this if I were … ’
And if you can’t uphold to that last one, at least have the decency to admit it. Add the comment:

sorry I know you will say WTF a lot when reading this code. I will buy you a beer for every WTF you need to say 

to your spaghetti.

Kthxbye

 

Leave a Reply