Over a million developers have joined DZone.

My Django Application Refresh: The Joys of Deleting Code

DZone's Guide to

My Django Application Refresh: The Joys of Deleting Code

· Web Dev Zone
Free Resource

Discover how to focus on operators for Reactive Programming and how they are essential to react to data in your application.  Brought to you in partnership with Wakanda

I've been refurbishing an older project -- written in 2008.  Probably with Django 1.0.1.  Certainly with Python 2.5.

The Django 1.3 release has been around since March.  The change underscored the importance of technology refresh.

The best part was to delete code.  There were two significant reasons.

  • The testserver command allowed me to eliminate a bunch of low-value test harness.   Without this command, we had to create our own test database, start a server, run integration tests, and then kill the server.  With this command, we simply start and kill the server.
  • The RESTful web services can be securely integrated into the main web application.  A simple piece of middleware can authenticate requests based on headers containing ForgeRock OpenAM tokens.  It may be that this was always a feature of Django, but over the last few years, we've figured out how to exploit it with simple middleware.


Few things are better than removing old code and replacing it with code written (and tested) by someone else.

In  addition to the deletes, we also rearranged some of the dependencies.  We had (incorrectly) thought of the Django project as somehow central or essential.  It turns out that a bunch of other Python libraries were actually core to the application.  The Django web presentation was just one of the sensible use cases.  A suite of command-line apps could also be built around the underlying libraries.

In addition to this cleanup, we also replaced the documentation with a new Sphinx project.  The project originally used Epydoc markup.  This meant that every single docstring had to be rewritten to use RST markup.  The upside of this is that we corrected numerous errors.

There Was Pain

This wasn't without some pain.
Was the cost worth the effort?  That's the real question here.

I think that many IT managers adopt a silly "If it ain't broke, don't fix it" policy that focuses on short-term cost and short-term value.  It ignores long-term accrual from even tiny short-term cost savings.
Here's are two important lessons. 

  • Money saved today is saved forever.
  • Savings accrue.  Forever.

It's important to avoid short-term thinking about cost and benefit.

Learn how divergent branches can appear in your repository and how to better understand why they are called “branches".  Brought to you in partnership with Wakanda


Published at DZone with permission of Steven Lott, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}