As developers, we are often rewarded with praise (or more) for turning new features around quickly.  If your company estimates that a particular feature will take eight hours to write, and you take only four, the company’s making a tidy profit, you can move to the next item in your schedule more quickly and everyone is happy.  This is all very well, so long as that feature has been written properly and in accordance with your company’s general approach; everything ranging from naming conventions right through to the organisation of the filesystem.  If it hasn’t been written properly, then you have incurred technical debt, and at a point in the future either you or another developer maintaining your code may need to spend more time writing a feature or changing your feature than anticipated.

This can cause all manner of problems.  When you come to develop on from your last feature, you might estimate that another bit of functionality will take 8 hours to write.  However, when trying to hook in to the existing feature, you discover your technical debt, and end up having to refactor the existing code to allow you to do what you wish.  This might take another 4 hours.  This might not seem to be a disaster; after all, you were 4 hours up on the first feature, and we’re just back where we should be now, right? Wrong! It is important to remember that managing our time isn’t  just about managing the absolute amount of time taken, but keeping to schedules.  The 4 hours it takes to sort out the mess in this second round of development delays the next item in your project schedule, which might result in a disappointed client.

In my opinion it would have been better to take the full scheduled 8 hours in the first round of development and avoid the unexpected hold-up during the second round of development.  The 4 hours in the first instance are less expensive than the 4 hours in the second, as they’ve less of an effect on surrounding projects & priorities.

The trouble is, at the time the new feature is written, it can be difficult for someone non-technical to tell the difference between it having been done quickly and it having been done properly.  In fact, from an end-user’s point of view, the system can look absolutely identical.   So, given two developers, one who can turn the feature around in 4 hours, and another who takes twice as long at 8 hours, which will the project manager or client be more happy with? My money would nearly always be on the 4 hour guy. But long term, the 8 hour guy is actually going to be less expensive to run, or will at least facilitate more accurate estimates and quotes on the same system in the future.  The problem is, as developers, we need to resist the temptation to be the 4 hour guy. The short term praise can be addictive and it’s understandable why it seems easier and more tempting to do things as quickly as possible and worry about the consequences later.

What I’m noticing is, in 2008 I WAS the 4 hour guy. I was turning around features faster than other people had in the past, and grew a reputation for being quicker.  While I was quicker at the time, now, 4 years on, when I’m revisiting those sites and starting to improve or extend them, I’m paying off my technical debt with ‘expensive’ rewriting and refactoring.  So now I’m in the position where I am expecting the implementation of a change request to take a given amount of time, but on loading up the project and seeing the way it was written in the first place, the implementation is taking much longer.  This extra development time is difficult to explain and to justify to those responsible for project scheduling, and is something that I’m going to really strive to avoid in the future, even if it does seem to take me slightly longer to develop new features than before.

It seems sensible to finish this post with one of the more famous quotes about computer programming. I’m sure you’ll have read it before…

Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live

Trust me, it’s bad enough even if it’s YOU that ends up maintaining your code!

The Concept

The concept behind this is simple.  Every developer can be responsible for the code in any project.  As mentioned above, this means that bug fixes can be made by any developer, and new features can be developed by any developer.  Here’s wikipedia’s current take on the matter:

Collective code ownership means that everyone is responsible for all the code; this, in turn, means that everybody is allowed to change any part of the code.

The Advantages

In my opinion this introduces the following advantages.

• If a member of your development team is immersed in an important project and needs to be allowed to “get in the zone” and work interruption free, then if code they have written is deemed to be broken, any other member of the development team can fix the problem.
• This increases exposure of application code.  The more developers that have seen code and got their head around the way it works, the better!  When the developer that wrote the code leaves, it would be helpful to have other people who have at least seen the code and knows that it exists!
• Fresh pairs of eyes can foresee other problems with the code.  Imagine constructing a delete query using a function called constructInClause, which is passed an array.  This will return an SQL IN() clause statement.  “Hang on a minute, what if the function constructInClause returns an empty string? Won’t that delete everything from the database?” – better to spot this before rather than after the bug is exposed.

The Disadvantages

With every new approach comes disadvantages alongside the advantages.  Unfortunately, I do see a couple with this one:

• Allowing other developers to fix bugs and modify code can mean that they will not necessarily bear in mind the full knock on effects of a change.  Dependencies on code working a certain way are commonplace – even if not ideal – in web based applications.  (Note: Unit Testing could probably avoid this situation!)
• There is a danger of one person in the office becoming the “bug fix person”.  Not many developers enjoy fixing bugs all day, so in my view it would be important to try to make sure that responsibility for fixing bugs is shared equally between the development team.

Will I be encouraging the company I work for to encourage collective code ownership?

Probably, yes!  It seems like a very sensible idea, especially considering that at times interruption to fix bugs is really quite infuriating!  If the bug fixing could be assigned to the “most interruptable” developer at any one time, I’m sure that productivity and developer mood would both be improved.

1. Make sure you understand the problem in full.

Generally, when we are presented with a problem by either a client, or a project manager, the problem has been simplified somewhat.  A 15 minute phone conversation or meeting is condensed in to a three sentence paragraph asking you the best way around a problem.  In my eyes, there are a couple of approaches to avoid this.

1. Be involved in the meeting, or the phone conversation.  This is not always possible – not every developer wants to be interrupted every 30 minutes by client questions, and not every developer is necessarily comfortable talking to a client.  But listening in on (and not participating in) a conversation could always be an option!  This means that you get to hear everything that the client has said about the problem.  It’s to be expected that the person relaying the message will miss out minor (but not necessarily insignificant) details.  After all, repeating every phone conversation in full could get a bit tiresome, you’d imagine!
2. Know to ask the right questions. A client asks to make their delivery fee increase with every product added.  Let’s say, increase the delivery fee by 30% for every additional product that needs delivering.  This is simple enough, until you consider that the delivery fee could easily escalate way out of control.  A £10 standard delivery fee could soon escalate to around £50 if someone bought a large amount of products.  This could discourage a purchase.  So should a limit be introduced for the maximum delivery fee?  Remember, the client probably hasn’t thought around this issue.  Asking the question and getting an answer before work starts could save you from having to rewrite a chunk of code.

2. If dealing with unfamiliar technology… allow some research time!

If you’ve been asked to implement an unfamiliar technology, take 10 or 15 minutes to research how it all works.  15 minutes spent now could stop you from estimating that something will take 5 hours when it might take 20, or from estimating 20 hours when it might take 5!   Additionally, when estimating how long the work will take, remember that you will probably spend a fair chunk of time reading documentation and not actually writing code.  In many places this would be considered billable time – and it should certainly be taken in to account when working out how soon you could deliver the work.

3.  Remember to allow time for testing and bug fixing.

Not everyone does this, but in my opinion it is essential.  Allow some time for proper testing and the time it’ll take to fix bugs (this can only be estimated) as well as the time taken to write the code in the first place.

4. If dealing with third party services, you can’t accurately promise a deadline.

A lot of the work I do involves integration with third party services – payment gateway services, SMS services, etc.  These all involve an account application and signup process, and sometimes this process depends on the client completing a form, or submitting payment for the service.   I have found that it is almost impossible to accurately estimate a “go live” date when an aspect of your application depends on a third party service being ready for use.  If you do provide an estimated go live date, it could be worth putting in a note that it depends on the client’s service X application being complete by date Y.

5. If you feel out of your depth, don’t be afraid to say!

This is a very important point.  If you are not confident about working with and fully understanding the technology that you will be using, tell your manager or your client! It’s better to say at this stage than to blindly assume that you will be able to work something out during the work.  They will be a darn sight happier this way around than if you go out of your depth and then the project is late or massively over budget.  Saying now typically will have one of three results:

1. Your company will turn the work away to avoid a problem (or, your client will go elsewhere).
2. Measures will be put in place to avoid the issue. Billing by the hour, or using another developer, for instance.
3. The project will be quoted anyway at an estimated rate, and your company will take a risk. In this case, you at least said something at the start – the risk taken was by someone above you.

These are only very basic steps that can be taken to avoid a problem.  But one thing is for certain.  It is typically better to under promise and over deliver rather than the other way around.  You just have to be careful that you don’t fall in to the habit of *massively* over-quoting projects, because this can have a detrimental effect in terms of reducing the percentage of accepted quotations.