Matthew Lang avatar

Matthew Lang

Family guy and web developer

Business Tools are the Exception to Simplifying

Despite my efforts to simplify my tools, there are some that I just need to keep using. They're just too important.

Yesterday I wrote about simplifying the tools I use in an effort to minimize the amount of data that I push around. I was all of sudden concious of having data spread across different services and the number of tools I was using to do this. Some things though require specialist software, like your accounting and invoicing aspect of your business. You can't simplify book-keeping and accounting without it having an impact on your business and career. Which is why the business critical software is the exception to simplifying the data and tools I use.

For a number of years I worked as an ERP developer for a company that provided development and consultancy services on a Microsoft ERP solution for small to medium size businesses. This one solution could meet most of the software requirements for your business. It has modules for accounting, inventory, customers, invoicing, purchasing and much more. That all encompassing ability run multiple aspects of a single business came at a cost though. It is a fairly complicated solution to run and maintain correctly. When used correctly though it becomes a critical part of the business.

My needs aren't so great that I need a solution like this, but I still need software to help me run my business. I require help with invoicing, accounting, time-tracking and expenses. Tracking all of these on my own just wouldn't make any sense. I have customers to invoice, projects to track, taxes to pay and more. I could do this on my own with a number of spreadsheets, an address book and some software cobbled together by myself, but that would require time to implement and it's not a valuable use of my time.

I use FreeAgent for all the requirements I just mentioned. It works, it's affordable and it doesn't require a steep learning curve to use. It does require some time to find out how to use effectively as a business tool, but that's why it's so great. I can use the parts of FreeAgent that I need to begin with and then gradually start looking into other features it offers to help me run my business. It then becomes a business critical tool. I need it to run my business. It's not complicated to use, but then it's not also so simple that I can switch over to something else if I wanted too.

Business critical tools are the exception to the rule when it came to cutting back on the tools I use. The trade off between using something simpler would have a negative impact on my time. I would end up spending more time managing my business data than I would delivering value to clients. It's not wise to cut corners when it comes to business critical tools.

In the pursuit of workflow zen, I've been simplifying things a bit. It's been a positive change so far.

Data is everywhere. We create and consume vast quantities of data everyday without giving a second thought to how much. Emails, tweets, posts, pictures, videos, messages and audio are just a few examples of the data that we interact with on a daily basis. And there's no shortage of software to manage your data either. For each type or format of data you have, there could be hundreds of different options available to you to manage that data. Apps, web applications, scripts, services, products.

Not only are there tools that mostly persist and manipulate your data, there's a new type of service available that pushes your data to other services based on triggers. Services like Zapier and IFTTT have the means to collect and distribute your data to other places depending on the triggers and services you specify. It can become mind boggling and complicated.

It was last year when I realised that I was pushing more data around different services than I needed. I started making some changes:

  • I stopped using a dedicated bookmarking service and instead opted to routinely drop a list of formatted markdown links into my blog.
  • I stopped using Evernote and instead starting using text files to manage lists and collections. Evernote is a great tool for keeping all your data together but I found it difficult to keep my data organised. The idea of notebooks and groups is good but I just couldn't make it work. This isn't a complaint against Evernote, it's a great tool, it's just not for me.
  • I started using plain text files for a lot of things. Check-lists, ideas, outlines and anything else that I needed to keep a note of.

After doing this I noticed a change. The number of places I need to check to find something was greatly reduced. I had a collection of files in my Dropbox that I used on a daily basis. Then there was my task manager, my reading list and a few boards on Trello. I didn't have to search anywhere else beyond that. Then the number of tools I needed started to fall as well. I started uninstalling apps from my MacBook and cancelling some subscriptions.

It's been a refreshing change. Gone are all the connected services and triggers I used and instead I have a low maintenance set of tools that I can use easily. I can find the data I need for easily and most importantly I do less moving about of data.

You sip coffee and make your list. At a nearby table someone is writing The Great American Novel but you are simply identifying your projects and actions. The list grows every time you pause for a sip. What is surprising is how items which once dominated your attention now require a reminder.

— Your List by Michael Wade

A little reminder from Michael Wade that lists are a great place to start.

Reading Redmine: Comments

Continuing my series on reading Redmine, we'll take a look at commenting.

Next to tool choice, comments is another topic that can cause heated debates amongst developers. As a rule, I rarely comment my own code. I just don't see the need to comment it. I try to be as expressive as possible in the code I write and although it usually is more verbose than other developers who I have worked beside, I know that by expressing my code, it becomes easier to read and understand.

Having worked on a number of different code bases for clients I've started to look at commenting in a different light. In the past I would rarely comment but now that I am working on code bases for different clients, it can be advantageous to comment your code. When I started reading the Redmine code I noticed a similar use of comments in the Redmine code to what I had in mind for commenting on my client's code. Here's what I found out.

Open Source License Everywhere

Having not worked on any major open source applications (yes I should rectify this), I was surprised to see the open source license located on each file within the Redmine source. Yes, within each file. Every model, controller, helper and almost all Ruby source files that I could see included a copy of the GNU General Public License (version 2).

My only critique against this is that if the license was to change then it could be something of a task to update the license on each file within the application, however in order to ensure that the license for Redmine is fully understood, then it does make sense to include the license in each source file.

The reason I have included this is that I do view the license as a sort of comment. It's not code but it's also not expressing the intent of the code in the typical way that a comment does. It does describe how the source code can be used so could be viewed as a comment.

Comments on Controller Methods

One thing that stood out from the source code was the use of comments on controller methods. This makes senses in the cases I seen, as some controller methods didn't follow the traditional RESTful verbs and some required an explanation of the intent of the method. It was good to see that a single or double line comment was frequently used to explain the controller's intent.

# Loads the default configuration</h1>
# (roles, trackers, statuses, workflow, enumerations)
def default_configuration
  # ...
end

This is good from a documentation point of view as it means that other developers working on the same method will immediately see what this method does. Most controller methods were fairly straight forward to read but there were a number that required just a single line to explain the method further.

Comments on Model Methods

Putting aside the argument of where the business logic in a Rails application should reside, let's just assume that in Redmine's case it is in the correct place, mostly within the ActiveRecord models. I say most as there is also a fair degree of code spread out into controller, helpers and in the lib folder too.

So if most of the business logic for Redmine resides within the ActiveRecord classes then where's the documentation for each method? It was something I found unusual given that the controllers were documented well. From scanning the models it was clear that only about half the model methods were commented. It should be mentioned that there were a number of methods that didn't require comments, but then there were a few places where a comment might have been advantageous.

To Comment or Not?

The Redmine source itself is a typical Rails applications without any architectural surprises. It shouldn't surprise most developers familiar with Rails that it is indeed straight-forward to follow. Given my history with commenting in Rails applications, I was surprised to see such a wide use of commenting within Redmine but without using RDoc.

It has given me food for thought on commenting on the Rails applications that I working on at the moment including my own. I've always just viewed my code as code the I alone will read but that may not be the case. If someone else was to read it, what would they think? That's an exercise for another day, but this look at commenting with Redmine has shown some good examples of where commenting can be an advantage.

Interesting new idea for home security. I would be interested to see how accurate it is.