Could Code Rot be Useful in Decision Making?

P7060031

Yes. Maybe. Allowing the codebase of FlyLaTex¬†to “rot” for about 7 months enabled me make better¬†decisions on what features to add and what features to remove.¬†It does seem contradictory. It seems¬†like code rot should always have an adverse effect on your¬†codebase.¬†It should break stuff, right. Well, it depends on¬†how you define code rot. My definition of code rot is a little¬†fine tuned, I must admit. Let’s step back a little.

Defining Code Rot: It’s harder than you think

You’ve probably heard of code rot in different contexts, mostly hinged on¬†the concept of legacy PHP¬†code. Wikipedia defines code rot as the “slow deterioration of software¬†performance over time or its diminishing responsiveness that will¬†eventually lead to it becoming faulty…” [1] Robert Martin wrote an¬†article called Principles and Patterns in which he lists the 4 signs¬†of code rot: rigidity, fragility, immobility, and viscosity.¬†On the other hand, a lot of people are still ambivalent on or¬†confused ¬†about the definitions of code rot.

These definitions are fine. But none of them recognize the power of active waiting (for programmers, of course. Not this) and its influence on feature adoption in software development. Most definitions of code rot just show how bad code rot is, how we recognize code rot, and how we can avoid it. Well, maybe we can harness the ROT. I think I did.

Code Rot in FlyLatex

I started developing FlyLatex for two reasons:

  • I noticed that collaborating on LaTex documents was painful.¬†But no free LaTex collaboration environments were available. So I set out¬†to create one.
  • The HackNY demofest was fast approaching.¬†I knew I couldn’t demo the product I was developing at Trendrr. FlyLatex was¬†a good enough product for the HackNY demofest.

I started developing FlyLaTex around early July and had to finish (for the HackNY demofest) by late July. As a result, I spent less than 4 weeks developing the product. It was 2nd priority (after the product I was working on at Trendrr).

During the development process, I had to make some quick decisions on how the LaTex writing and compilation flow should work. Where should the documents be stored after compilation? Should a user be able to compile LaTex documents remotely or not? How should the compilation errors be presented to the user? I had just learned about Amazon s3. My gut feeling at that instant was to store the compiled PDFs on s3 (via mongoose-attachments) to ease remote hosting. It seemed OK at the time.

This meant that to use FlyLatex, you’d have to have an s3 account.¬†BAD IDEA.

After a couple of minor iterations, I had a working product. FlyLatex¬†v-0.5.0 Beta was born (Beta in this context meant–use at your own risk).¬†My demo at HackNY was pretty successful (except for some minor¬†hiccups,¬†of course). People seemed to like it. I was OK with the product. But¬†no one used the product, I noticed. I got pretty discouraged because¬†of this.

HackNY passed. Sad moment. My internship at Trendrr passed. Fall semester began. I was studying abroad in Budapest during the Fall.

The Hiatus

From the beginning of September to the end of December 2012, I didn’t contribute a line of code to any of my github repositories.¬†I was too engulfed in the rigor of the Budapest program (plus, the¬†wonderful scenary of Budapest and the rest of Europe).

hiatus

This is when the code rot started! It ended a week ago (on the 17th of March).

Harnessing the Code Rot

A week ago, I pondered using FlyLatex to collaborate with a classmate on an abstract algebra project. I tried to run it. It broke, spewing several errors. I was stunned. The last time I ran FlyLatex, it had no problems.

I spent some time trying to trace the main source of the error. It came from the mongoose-attachments.js include. Apparently, mongoose-attachments.js had changed significantly. The developers of the library decided to separate the amazon s3 upload functionality from the rest of the features. That change broke my code.

whatthinking

Then the epiphany came.

I wandered why I decided to use amazon s3 to store compiled PDFs in the first place. What was I thinking?! It’s much easier for the users¬†to store the compiled PDFs in a directory on the current server anyways. [2]¬†I decided to store all PDFs in a subdirectory of the FlyLatex repository¬†by default.

It took me less than 30 minutes to change the source code (and the README correspondingly) so that PDFs would be stored in the local filesystem and not in an Amazon s3 bucket.

After the change, I posted a link to the repository on HackerNews. People seem to like it.

Should you need to make some major (or even minor) decision about your software, maybe all you need is to allow your codebase rot for a little bit.

[1] http://www.cincomsmalltalk.com/userblogs/buck/blogView?entry=3320476400

[2] This is one of the many perils of developing code alone. Had more than one developer been working on FlyLatex with me, I feel we should have to the later conclusion a long time ago.

FlyLatex: A Real Time Collaborative Environment. Some Screen shots of the App

Visit the Github repository of the Free and Open Source FlyLatex app here for more information.

Enjoy!

JSON Pretty Print and JSON Multi level Collapse Code in Javascript and Python

If you are the type of programmer that deals with JSON objects a lot, you¬†are probably familiar with some online programming tools to print out the¬†JSON in a very “pretty” format. These tools not only make dealing with JSON¬†easier and less frustrating but, I must admit, make it more fun too!

A “JSON viewer” app that I use regularly to “pretty-print” complicated JSON objects is at jsonviewer.stack.hu. The app has a very intuitive interface and is thus really easy to use. You can just copy a JSON object to the front page of the app¬†or pull a JSON object from a remote location and then “format” the json.¬†There are many more helpful JSON viewer apps and extensions that are¬†helpful for viewing JSON.

Have you ever had the problem of trying to “pretty-print” your JSON object¬†in your program or app for users to see, or to “collapse” your multi-level¬†JSON object (which might contain arrays in objects and objects of arrays and …)¬†programmatically into one level? I have certainly. Programmers that¬†usually have these problems regularly use or make RESTFUL api calls ‚ÄĒ¬†although RESTful “resources” can be transmitted in XML, SOAP, or even YAML,¬†the predominant format on the web is JSON.

“JSON multi-level Collapse” Code in Javascript and Python

I cooked up the “multi-level collapse JSON” algorithm three days ago because¬†I needed to, given a bunch of streaming JSON objects, collapse each JSON¬†object into the most minimal form and then assemble the JSON objects into a¬†CSV file where each JSON object occupies only one line in the CSV. Yes, my¬†program had to first collapse any JSON object (might contain embedded objects¬†or arrays of objects of arrays of objects of…) into a one-level JSON object¬†without losing any information.

“Multi-level collapse” code in Javascript

“Multi-level collapse” code in Python

For example, the output of the “multi-level” algorithm on input the JSON¬†object

is

“Pretty Print” Code in Javascript

The goal of the “Pretty Print” code is to, given a JSON object (usually¬†used for complicated json objects that’s multi-level and really nested),¬†print the JSON object in a very clear way so that the user sees the¬†embedded arrays, embedded JSON objects, and embedded arrays in objects and¬†vice versa present in the initial parent object.

So for example, the output of the “pretty print” algorithm on input the¬†JSON object below

is

The “pretty print” code in Javascript

It’s just a simple line of JS but not many people know about how to pretty print using an already existing function in JS.

For more information, check out the MDN Docs