Technical Debt

In the debate between developers and their employers, fixing technical debt is often seen as a cost centre, a time suck that takes away from feature work. After all, when there are features to ship and clients to satisfy, taking the team off such projects so that they can rewrite what already works is seen as silly, costly or foolish.

But smart employers recognise that technical debt is more than an annoyance or a cost centre. They recognise that technical debt has a chance of costing them good developers.

Developers hate technical debt. It's annoying, it's frustrating, and the struggle to find time to fix it is constant. Developers hate technical debt because it makes their jobs harder. It makes solving other problems harder. Technical debt, from a developer perspective, really sucks.

The problem here is that frustrated developers are unhappy developers. Unhappy developers have a tendency to quit. And given the fact that hiring developers is tough under the best of circumstances, this means that technical debt is actually costing your team skilled developers. And this costs money.

The loss of a single developer can cost a company £20,000 - £35,000, depending on the costs of replacing that developer. And the skills and knowledge they take with them can never really be replaced.

When considering whether or not to fix technical debt, it's worthwhile to consider the frustration level of your development team, and the cost of replacing just one of those developers if they should choose to quit. Is the cost of fixing the debt less than the cost of replacing a developer? If so, the tech debt should be paid down, until the developers are happier and satisfied.

Refactoring: rename class/method/variable

This refactoring is such a simple idea and you'll find yourself continually doing this as you work and build extra functionality into your web applications. There is also continual need to do this whole debugging and/or refactoring existing code.

Take for example the below class:

class person {

  public $w;

  function clchrlypr() {

    // calculate hourly pay rate of employee

    ...

    return $var;

  }

}

Now let's look at the below example:

class employee {

  private $wage;

  public function calculateHourlyPayRate() {

    // do some magic

  }

}

Which was easier to read and follow?  I would hope the second snippet was clearer, however the first is an all to common sight in some projects and seeing this code makes you really have to think hard, and quite frankly wastes time  if we had written the second block of code in. The first place things would have been so much easier for our colleague.

Legacy Code Change Algorithm

When working with legacy code, it is very easy to get carried away and make a big bang refactoring (actually, 'code cleanup and pray' is a better term since we do not have any tests). In this case, we can try to eliminate the static cling by making the static method non static, and extracting the non-static method into an interface. Make the clients (all the call sites) use the interface. This would mean that we deal with potentially a few changes to the client code to a few hundreds in some worst case scenarios, all at one time. The result could be 'Object Reference not set to an instance of an object'. We want to be able to make this change in a phased manner in small manageable increments.

Approach

1. Pick one call site.
2. Change in one call site.
3. Bring it under the safety net of unit tests.
4. Make sure the change works.
5. Meanwhile, the other call sites continue using the original unchanged code and continue to work fine.
6. Go back to step 1 till all the call sites are refactored, and remove the static method finally.

Let us see how these steps map to one of the techniques in eliminating static cling, 'Introduce instance delegator - p369, Working Effectively with Legacy Code'.

Introduce Instance Delegator

1. If the class which contains the static method is static, make it non static.
2. Introduce an instance method with the same signature which delegates to the static method.
3. Use ExtractInterface and extract the instance method created.
4. At the call site for the static method, change to use the instance method (called through the extracted interface) instead of the static method.
5. The instance can be provided at the call site
• as a parameter
• via setter injection
• via constructor injection

Most importantly, the other call sites continue using the static method till we get them under the safety net of unit tests.

Increase conversion rates - the easy way

When your business is online, conversion rates are hot on the list of KPI's to watch month on  month, year on year.  But what are conversion rates, and how do we increase them?

In terms of an ecommerce site, be this physical goods or e-goods, for example ebooks or services, the conversion rate on your site is essentially the percentage of your visitors who you manage to convert into paying customers.  People who visit your site and decide, you know what, I've just gotta have this!  And if you can make them impulse buy - even better.

Here are some quick tips to increase your conversion rates:

1.  Explain the benefits - 3 C's

• Clear
• Concise
• Consistent

Summarise the benefits and sell your product or services as clearly and concisely as possible.  Let your customers know what they are paying their hard earned cash for, and let them know quick.  Why waffle on for pages and pages?  When you meet someone in person, they make their mind up about you in the first 30 seconds of the conversation.  Giving someone the key benefits upfront can boost your conversion rates by as much as 150%.  If you do feel the need for a more detailed description, be consistent with the key benefits you first mention so no one misses out.

2. Collect Customer Feedback

Customer feedback is key to improving your site and giving customers what they want.  Services that prompt for feedback on Products and Services such as Feefo and Trustpilot are great, but what about general site experience?  Services such as Qualaroo and WuFoo are great for general usability questionnaires.  Ask questions such as

• What information is missing from this page?
• What can we do to improve our site?
• Would your recommend our site to a friend?

3. Make your site easy to use

Another great tool for gathering feedback is iPerceptions.  iPerceptions offer a free short survey to your web customers.

• How would you rate your site experience?
• What describes the primary purpose of visit?
• Were you able to complete the purpose of your visit today?

Using feedback you can prioritise content on your site. You may receive feedback from customers looking for particular brands or wanting to compare 2 or more products. This information may be available on your site, but nested deep in the site, or require many clicks. Why not create a landing page with the most popular selling brands or products on the site, or comparing the 3 most popular electronic gadgets that visitors want.

4. Contact visitors that abandon

Email marketing shouldn't be underestimated in upping conversion rates, visitors who abandon during checkout, almost bought from you. Studies suggest you have a window of 90-120mins to finalise the deal or they'll go elsewhere and forget about you. A personalised email to visitors, reminding them of their shopping cart, complete with easy to follow links so they can continue where they left off should help. Let them know it's the last one in stock, or if they buy now they qualify for reduced delivery or a free pen! Everyone likes a freebie.

In review.

Increasing the conversion rate on your ecommerce site needn't be all scientific with graphs and numbers. Listening to your customers and providing a personal touch will let them know you care.

Refactoring: Push down method

Previously we mentioned the pull up method we can use during refactoring our code. The push down method is the exact opposite. Let's start with some code:

abstract class animal {

  function bark(){
    // bark here
  }

}

class dog extends animal{}

class cat extends animal{}

$dog = new dog();
$dog->bark();

Maybe one day our cat had a bark about it, or maybe we've coded an if statement to do something different like return false if it's a cat. 

abstract class animal {}
class dog extends animal {
  function bark(){
    // bark here
  }
}
class cat extends animal {}

$dog = new dog();
$dog->bark();

PHP Refactoring: Pull Up Method

As projects grow organically it is important to continually be refactoring your code base.  One simple refactoring technique which is often overlooked is called "pull up method". This is exactly what it says on the tin - pulling a method up in the hierarchy of its chain so it can easily be reused. Let's take an example:

class vehicle { }

class car extends vehicle {

  function accelerate() {

    // code here

  }

}

class motorbike extends vehicle {

  function accelerate () {

    // code here

  }

}

We can clearly see the duplication above of the 2 accelerate methods. What if e pull these up into the vehicle parent class?  Lets see how:

class vehicle{

  function accelerate (){

    // code here 

  }

class car extends vehicle {}

class motorbike extends vehicle {}

Refactoring: Replacing inheritance with delegation

All too often inheritance is used in the wrong scenarios. Inheritance should really be used when it makes logical sense, however we often see it used for convenience. Take this example:

class sanitation {

  public function washHands(){ 

    return "cleaned";

  }
}

class child extends sanitation { }

$child = new child();

$child->washHands();

In this instance child is not a "sanitation" So inheritance doesn't actually make sense here. We can refactor this to delegate handwashing by passing an instance of sanitation into the child constructor and calling it that way.   Now let's look at this example refactored child class:

class child {

  public function __construct($sanitation){

    $this->sanitation = $sanitation;

  }

  public function washHands(){

    $this->sanitation->washHands();

  }

}

$child = new child(new sanitation);

$child->washHands();