On software improvement

Modernizing a 6 year old application
May 17, 2016 by Michael

As you may know, I’m running the daily photo project Daily Fratze for more then 10 years now. What started as a simple PHP script in the late summer of 2005 grow into a Ruby On Rails application during 2006 and in 2010 i started writing the current version in Java, based on the Spring Framework. During those all those years, my database model stayed practically the same and has mostly seen additions so far.

I may have written it before, but Ruby On Rails was, despite all its hype, an eye opener for me. I was so deeply into desktop software, i really had no clue how to write web applications at that time and visiting some courses explaining J2EE (which Java EE was called backed then) didn’t help a lot, quite the contrary.

My love with Ruby On Rails last for over 3 years but our relationship broke eventually as I faced the several migrations from Rails 1.1 to 1.2, several 2.x and finally to 2.3 that really hurt though I did things as “in the book”.

The codebase I started in December 2010 is pretty much the same and something I’m only proud of as it was my way to come up with something like this and other stuff I do for a living.

Otherwise I wouldn’t really code anymore like this.

The last 1,5 years I didn’t do much on the site. I regularly updated some projects that have been extracted from the application but that was pretty much it. I put time into my Java User Group, the biking site and especially and certainly most rewarding, my family.

If you leave a software alone it ages and often not in good shape. If you skip a version of the libraries you’re using and then some you’ll often find yourself in a trap where one upgrade lead to dozens of others and minor upgrades that would bring security fixes and the likes leads to all kind of problems.

It didn’t come this far with Daily Fratze, i was only one version behind until last weekend, but this is how it starts.

Through my work with Spring Boot the last 2 years my first intuition was something like “Throw all but the entities away and start from scratch with boot” and I actually have 2 version of a new application floating around. One I started in December 2014 / January 2015 but abandoned very soon. The turn of the year 2014 to 2015 wasn’t a good time for me. I was highly depressed and for the first time in my life took an antidepressant and not only self-educated myself with beer. The question why programmers so often tend to run into this kind of problems is worth at least one another blogpost.

After somewhat finishing my biking application by even co-writing a book about it, i needed something new todo and startet a second try rewriting Daily Fratze from scratch and actually had some nice results this March.

But then I listened to Gernots Talk about the aim42 software architecture improvement method which needed some weeks to sink…

…and lead to asking myself the following questions

  • What are the main problems?
  • I’m I still happy with the UI or more specific (my) UX?
  • What is the cost on my family life creating a really complex and feature rich thing like the one I have again?
  • Can a brownfield project teach something I cannot learn on greenfield?

Outdated dependencies can become Daily Fratzes main problems. The UI, which pretty obviously has 2010/2011 style just works fine for me. It isn’t responsive in todays sense, but works better than half the Bootstrap based themes I tried and has less bloat. Yeah, it’s mostly still server side rendered HTML but guess what, I like it that way.

That leads to second: Yes, it does all the things I want and most of the stuff my faithful users want and are accustomed to.

The impact to my personal life was immense in March and April. Before going on a 9 days bike trip I was again at the edge of burnout. Working 9 to 10 hours a day, being a father and then coding until late after midnight takes its toll. Been there, done that. Don’t want to be there again.

And last and most important: As much as I dislike the way I programmed 5 years ago, I was the one writing down most of the requirements, listend to users and implemented it. So I know what is down there and I can change it for the better without the dead weight of not knowing why stuff is there.

Some weeks ago, on my bike in Denmark, I made the decision to stop working on a new version and made the old one a better one.

I started by upgrading all the dependencies (apart from the ORM, where I have to touch to many queries) and reduce most obvious coding style flaws.

That version went live on the weekend and already is faster:

First and immanent problem solved and fixed several bugs that neither me or a user has noticed before on the way.

The next thing on my list is: Writing real tests. I had no clue how to really do this 6 years ago. The tests I have crap and much of the code isn’t actually testable right now. So writing tests and changing stuff to actually be able to will have a significant impact.

So far, I’m really happy with my decision. My problem isn’t on the surface, I’m happy with the UI. And I’m happy with the algorithms I wrote. I’m not happy the way I wrapped them, packaged them and so on.

Gernots hint on stepping back and having a look at the bigger picture is of great value and even if its a pretty obvious hint, we rarely do this if we have the “start from scratch” option at our hands.

One comment

  1. Gernot Starke wrote:

    Michael, thx for the post – I appreciate you could take some ideas from my talk and aim42.

    Posted on May 31, 2016 at 10:46 AM | Permalink
Post a Comment

Your email is never published. We need your name and email address only for verifying a legitimate comment. For more information, a copy of your saved data or a request to delete any data under this address, please send a short notice to michael@simons.ac from the address you used to comment on this entry.
By entering and submitting a comment, wether with or without name or email address, you'll agree that all data you have entered including your IP address will be checked and stored for a limited time by Automattic Inc., 60 29th Street #343, San Francisco, CA 94110-4929, USA. only for the purpose of avoiding spam. You can deny further storage of your data by sending an email to support@wordpress.com, with subject “Deletion of Data stored by Akismet”.
Required fields are marked *