Mr-F.org

For a number of weeks I’ve been research time tracking solutions. Between the three of us at Tauri-Tec we have identified the need to be able to more accurately track the amount of time we spend on individual projects, which should aid us in a number of ways.

Firstly, we should be able to quote more accurately for future work. The issue here is being able to judge the pace someone works at. This obviously differs, depending on their experience with not only the language, but also the project itself. The modification might only be a small one, but if you don’t know the project it’s going to take you longer to make the modifications required than someone that knows the project inside out. Also some people just seem to work faster on some things than other. I know back when I joined the company, that Ed was constantly over estimating how long it would take to complete parts of a project. Now you could be thinking “what’s the problem you get some down time”, but in all reality it actually means we are losing money. For example, it could be that we have several parts to a particular project that need to be done with a short space of time. If we have over estimated how long it will take to complete a particular part, then it might lead us to pay someone else to complete the other part, which is more expensive than one of us working on it. Not only in monetary terms, but also checking it against our QA standards. So having data on how quickly people work both; full time employees and freelancers that we use, will allow us to better judge costs, which also means we can be even more competitive when quoting for work.

Secondly, and this is actually something Damian pointed out. It’s nice for a customer to be able to see where the money is being split when they receive an invoice. Damian recently engaged a lawyer to help with drawing up some particular contracts. Attached to the invoice was a break down of not only what work was done, but also a brief outline of the number of hours that were spent doing different activities. Our company has clients that pay a maintenance contract, where they pay us to monitor their system, apply small updates, and fix any bugs that pop up from time to time. So this would be very helpful for these clients. However, and this is more important for us, we can more accurately monitor the amount of time we spend on these maintenance contracts, and then modify the service agreement for them. For example, if we aren’t spending as much time that our agreement covers, then we can re-visit this agreement and decrease the cost. Alternatively, if we are spending way over the amount of time that our service agreement covers, then we can again sit down with the client and discuss the possible need to increase the service agreement so that it covers the man hours that we are spending on their system.

So now we have determined the need, I’ve been given the job of finding a solution. As I see it I have two options, take some pre-existing time tracking software which nearly matches our specific needs, or write my own.

Over the last couple of weeks I’ve been thinking, is there such a thing as being a “code snob”, and if so am I one?

The reason I’ve been thinking about this is that I have been slowly picking up more and more small projects, where I’m having to either repair or update the existing code, which were created by other companies. Nine times out of ten I find myself starring at badly written code. For those of you not into programming, there are a number of metrics that can be used to classify how well code is written. I spent ten years being both taught and teaching students how to write “good code”. The majority of these rules are simple to follow, and are even common sense. For example, “name variables appropriately with a descriptive name”, so when you need a variable to store the total of a sum you might call it “total”, but don’t call it something random like “b” or “jklgh” (and yes I’ve seen undergraduate students do this).

The reason we have these metrics and guidelines to writing code is pretty simple. Good code is easier to read and understand, which means when it comes time for you or someone else to modify the code it will take them less time and more importantly be less frustrating. Whereas badly written code is just a nightmare to understand, let alone alter. I’ve even heard young developers say, “well it’s my code and I’ll be the only one that will be modifying it”, which is giving them false hope. Generally you as a developer will work on a piece of code and then move onto something new. Sometime later, could be a couple of months or a couple of years, you will need to revisit this code and make alterations to it, and trust me when I say you will have forgotten some of the fine details of why you did things in certain ways. Now if your code is well written it won’t be a problem to work everything out, but if it’s badly written code then the problem starts. There isn’t an excuse for badly written code.

My biggest pet hate, and any of the students I’ve taught programming to vouch for this, is code indentation. Some people say you must use tab characters to indent code, whilst others say spaces. Personally, I don’t care how you indent your code, just as long as you do and that you are consistent and use the same indentation throughout your code.

There are so many resources around to day that there is just no excuse for writing code badly. Even if you know you are never going to look at the code again, have a heart and think about the next person that will. You know the old saying what goes around comes around.

So to answer the starting question is there such a thing as being a “code snob”, I still don’t know. However, if there is then I think I might have membership to that club.