Back during the later part of 2011 there was a common theme occurring in our retrospectives each week. How can we replicate our live environment as close as possible?

We took steps to achieve this goal by creating a single machine image to ensure all our machines were configured correctly. Another quick win was to ensure certain aspects of our live data was restored to our local development databases during the night. This enabled us to take stack traces from our logs, and quite literally paste them into our IDE and replicate the users problem instantly. Without the same data set we could have seen different results. Despite these positive steps, there was a missing link in our replication process. How do we simulate the traffic of our live environment? As an example, we average anywhere from four to five thousand calculations per minute with our current web services, with our local and demo environment no where near this figure.

During 2011 I found myself involved in many deployments in which despite heavy testing I was uneasy. On our demo environments we could throw the same amount of load against our services, yet sometime after deploying our service would fall over. We would quickly have to revert and go back to the drawing board. The problem we had despite our traffic being mimicked in terms of volume was the load was not real. Our customers however have many more variations of requests that we were simply not predicting. The other obvious issue was during local development, the service may well handle the same volume of traffic, yet once live and the process has been running for a few hours – things might go bump. Factors such as memory or timeouts being the culprits here.

Collectively we had a few ideas on how to solve this. We looked into low level solutions such as directing traffic from IIS/apache towards other servers. We examined other load testing tools, and we even contemplated creating our own load creator. This internal tool would go over our database and fire off a number of requests at our demo environment. I felt uneasy with all these solutions. They were not “real” enough. I wanted the real time traffic to be submitted to our demo services, only then could we have full confidence in our work.

My idea was rather radical in the sense it was so easy, yet dangerous enough that it might just work. I proposed we integrated our own service, into itself. In other words, just before our service returns the results of the calculation, it takes the users request and submits it again, against our demo environment. The same service would be recursively submitting into itself. In order to ensure we did not affect the speed of the service, the submission is performed via an async call, meaning if this second call was to die the live service would be unaffected. The obvious downside here was that in order to test this, we needed to deploy the changes to our live service. This was achieved via a feature toggle, meaning at any time we could turn the feature on or off without affecting any customers.

The end result of this was that when the feature is enabled, the traffic on our live service is sent to our demo service. This allows us to deploy experimental or new features and changes to the demo environment and check them under real load, with real time data. If all goes well after a period of time we can deploy to our live service, if not we roll back and no one is the wiser.

One thing that annoyed me when starting at Codeweavers was the amounts of warnings that would occur during a build of any of our projects. Seeing the build progress only to spew out a screenful of text was something that did not sit right with me. I was not the only one who felt this was wrong, but as there was so many warnings in some cases, it was easier just to pretend they were not there. After all everything was working fine.

The broken window theory is very much in action here. During our last standards review we decided that there should ideally be zero warnings per project. It is worth mentioning that most of our warnings were just that, warnings about something that was not really a major issue. Warnings such as unused variables and so on fall into this area.

On the other hand, while 90% of our warnings were ignorable, there were a handful which were rather important. Examples such as referencing different versions of required .dlls. Warnings like this are extremely helpful. It would be wrong for these to be hidden among a block of less serious issues. Warnings such as these once visible, can save hours of painful debugging.

Some of our projects had a fair few warnings – in the region of fifty plus. In order to begin tackling these larger projects we started slowly. If in a single day I would have removed a batch of warnings, this was a step in the right direction. After a week or so all our projects were void of warnings.

The next step was to make sure we do not go back to having larger projects with warnings galore. To prevent this I enabled “Treat warnings as errors” within Visual Studio. This is per project setting and can be found under the “Build” tab. Do note that you must enable this for “All Configurations” otherwise any settings you change will only apply to Debug/Release builds.

Enabling warnings as errors

I like this feature of Visual Studio emmensely. Having the compilier do as much work as possible – in this case check for warnings is similar to a tip found in Working Effectively with Legacy Code. Here the concept of “leaning on the compiler” is introduced. In other words you introduce an error in order to show you the usages of a piece of code – this is stark contrast to manually searching for the code in question.

The end result of this process is now during a build, if any warnings occur, the build will fail. The build will report where the warning is, along with why there is a problem. While this is great in theory it can cause some slight pain when developing, as you may comment out some code to experiment only to find the build failing due to unused variables. Despite this treating warnings as errors has been a great help. Recently we have solved some pretty serious issues with regards third party dependencies all thanks to treating warnings as errors.

The idea of allowing the computer to do as much work as possible applies to all languages. For your compiler/interpreter etc… there will be an option to apply warnings. This is not a specific language feature.

By basics, I mean things like:

• a deep seated empathy for what your customers want
• how to create a compelling case for why people should buy from you
• copywriting and design
• measuring response rates and web traffic effectively

Take a look at this list. How comfortable are you that your website demonstrates a strong performance in each of these areas? If you are comfortable that you have these boxed off, then I would indeed agree that going for the very latest in web technologies should indeed be your next goal – you have obviously got the basics in place, and are refreshing them regularly.

If you require some help with the basics, then of course you can engage web marketing consultants and/or read up on the subject matter yourself. Just bear in mind that unless the basics are right, then the rest will be built on shaky foundations.

A good analogy is that of the sushi chef. When they first start training, they are sometimes simply tasked with making the rice for the head chef – sometimes for months or even years. The idea is that if the rice isn’t right, then it doesn’t matter what you do – your sushi will be hopeless.

One suggestion for making a real improvement in this area is to concentrate on small incremental improvements to your web strategy, rather than wholesale changes that are implemented in unison. The main reason for this is that when you implement a single change you can monitor its effect on your business. If you were to implement a series of changes at once, then you may struggle to measure where any success or failure is coming from. Sounds like common sense, but is rarely done.

Also, try and make your customer’s web experience as difficult to imitate as possible. Many dealers will look at other sites and try to adopt or plagiarise ideas or functionality, but if every site offered exactly the same then there would be no differentiation at all. It would be much better if you enhanced your site by being able to demonstrate what makes you different, and what shows you care. These are the aspects of your web offering that then become very hard for anyone to replicate. Remember, many customers will have had bad experiences of the motor industry, and this is a real opportunity to show you are customer focussed. How about a short website video from the MD, highlighting what you do differently from anyone else? It puts a human face to your business that becomes difficult to copy. Of course, you need to make sure you live up to the promises that are made, but that’s another story.

In order to make it easier for the customer to forward a proposal form to a Dealer, we have made the Bank Details section of the form optional.
As the customer can now skip this section it should be more likely that partially completed finance proposals are submitted.
There have traditionally been two reasons why the customer may not complete the bank details section:

- they are uncomfortable putting their bank details on a website form (even if that form is secure)
- they don’t have their bank details to hand at the time

The Dealer can then make contact with the customer and request the bank details in order for the proposal form to be competed.

Don’t be afraid to change the tests! As soon as you’ve verified that you’ve transcribed the code correctly, don’t be afraid to just nuke things and start again. Especially if you have integration level tests that confirm that your features actually work, your unit tests are expendable. If they’re not useful, kill them!

A few people on Twitter found this odd, and I’d have included myself in this statement a while back.

https://twitter.com/F1nglas/statuses/160776765353111552

Kent Beck’s TDD screencasts changed my view on deleting unit tests however. During the later videos, he actually deleted some tests. Pretty much all TDD resources don’t really mention this. One of the key points beginners learn is that if you break any tests, you’ve introduced a regression. This is not always the case. If you follow the rule of never deleting ANY tests you encounter you are going to be stuck with someone else’s implementation forever. Likewise unit tests are there to drive design, not enforce how something works. I remember discussing deleting unit tests with my work colleagues and finding Kent’s videos pretty shocking at the time. I mean deleting unit tests!?

The more I do TDD, the less this statement becomes so jarring. For example.

[sourcecode language="csharp"]
public Result DoSomething()
{
// Implementation here.
// Pretty straightforward.
return result;
}
[/sourcecode]

Consider a test for the above behavior, such as we get the result back in a particular state. Pretend the logic is rather simple, and it does not warrant a separate object. Any other developer should be free to come along and change the internals of this method. As long as we get a result back in the correct state, the test should be valid. The test should not care that we are using strings, lists or whatever internally.

Occasionally I find tests like this hard to pass. In other words, I feel like the logic is correct yet the test fails. Maybe I’m using a new language feature, or a language feature that seems to be not working as I expected. If so I’ll break out a new unit test that tests the implementation. Such tests are often refereed to as learning tests. Here with a smaller focus I often become aware of what I’m doing wrong. Following Kent Becks example, I ditch the test after and move on.

I feel this sums up my feelings nicely.

https://twitter.com/avdi/statuses/160780747827974145

I and others are not saying bin every unit test you have that is covered by end to end tests. Unit tests are great, you can run hundreds in a matter of seconds. They have their place as part of the development process, but do not find yourself working against them. However I am saying you should delete any test which relies on implementation details. I am saying bin any test which does not make sense. I am also saying bin tests as part of a refactoring session as long as you have test coverage higher up. If you don’t have test coverage such as acceptance tests, you cannot be sure you have not broke anything after the refactor.

Any developer worth their salt will know what logging is. You could argue there are two types of logging, either developer logging or auditing. Developer logging would be what we log when something goes wrong. Using the results of this logging we can track down what went wrong, and put fixes in place to stop this event from occurring again. If this logging fails, or logs the incorrect thing it is not the end of the world. Due to this, I generally do not care for testing such scenarios. The code should behave the same with our without this logging.

Auditing would come under logging which as part of the application needs to be carried out at all times. Consider visiting a cash machine. When withdrawing fifty pounds, you want to make sure your bank logs this in case anything goes wrong. This sort of logging is crucial, and must work and must log the correct data. This is considered a feature, therefore this should be tested as it is part of the behavior of the application.

When I think back to my first few years of programming my code was littered with logging. In the early days after each statement, variable and function I would print out what happened, along with any errors that happened. In fact I’d say that everyone starts out like this. The strange thing is as we get better, the logging becomes less and less. Rather than the first class citizen we relied on in the early days, logging is seen as boring. The problem with treating logging code as a second class citizen is that when things go wrong, it can be very difficult or near impossible to track down what has happened. When you realise you need logging, its often too late. You will need to redeploy the application and wait for the problem to expose itself again.

Back in 2011 we had a difficult problem to track down. The dreaded “OutOfMemoryException“. Being the cocky developers we were, we decided to add the logging last. After all, it was there for when things went wrong. We never planned things would go wrong, after all it “worked on my machine“. After redeploying the application with logging we managed to track down roughly what was going wrong, and in turn began to resolve the problem. Had we added this logging initially, we could have resolved this problem in half the time.

The lesson I learned here was simple. Any time you have an error, log it. If the logging is not in place, we add it. Creating a new application? In the first iteration(s) make sure some form of logging is in place. I believe by following this simple rule any future issues can be handled easier. Logging should be a first class citizen regardless of purpose.

Around the same day I had this revelation, the image above popped into my Twitter feed. Image via @olafurw

It was once thought a physical impossibility that a human being would ever run a mile in under four minutes. Yet following Roger Bannister’s achievement in 1954, sixteen runners went on to do the same thing in the next three years. It’s not that human evolution had suddenly taken a spring forward – it was just that there had been a change in mindset.

As there are still many dealer groups that feel they need to withhold certain information from their customers, I think it’s time that there was a similar ‘change in mindset’. I am also aware that I need to be able to evidence that there is a solid business case for doing so.

So today, I would like to ask you to do something for me. Just key the letters ZMOT (pronounced ‘Zee-mot’) into your search engine and soak up as much information as you possible can. Maybe unsurprisingly, the term has been coined by Google, and in my opinion highlights the continued impact of one of the biggest shifts in online consumer behaviour.

If you take your web strategy seriously then ZMOT is something that you cannot afford to ignore. It stands for Zero Moment of Truth, and it refers to that period of online consumer research that a customer undertakes prior to making contact with a seller.

Traditionally, there has been a three-step mental model of marketing:

First, the STIMULUS, where an advertisement for a car first attracts attention. Secondly, the FIRST MOMENT OF TRUTH, where the customer calls in to the showroom to look at the vehicle and goes on to buy the car. Finally, there is the SECOND MOMENT OF TRUTH, where the customer enjoys their new car.

The net has now added the ZMOT to this list. It slots neatly in between the Stimulus and the First Moment of Truth, and involves the customer going online to look at reviews for the car, or to find out more about customer service at your dealership. In more and more instances, the customer has actually made their buying decision BEFORE they arrive at the showroom. The cold facts are that online decision making is rocketing, yet many motor dealers are only spending a fraction of what they should be spending on online marketing.

Your online customers want to research, learn, explore, and then come to you ready to buy with confidence. By not giving them the ability to conduct this research in an effective manner then you will more than likely send them elsewhere.

And don’t forget that it is so easy for people to share how well (or badly) they have been informed by your website or business. So if you allow people to research their next purchase online, they will be more likely to tell people how helpful you were.

It is possible for you to make it easier for people to buy from you at the Zero Moment of Truth stage. You could incorporate customer ratings and testimonials for your business, or include proven functionality such as the integrated Codeweavers finance calculation and payment search services. Either way, the strategy of trying to withhold information from the web customer is looking a bit outdated and ineffective.

Designed to provide Volvo web customers with an enhanced experience, the Codeweavers supplied service highlights how affordable a used Volvo can be when purchased with dealer finance. The calculators allow customers to specify their own PCP and HP quotations based upon the Volvo Car Financial Services product rules. The customer can request as many calculations as they wish, allowing them to model different scenarios for deposit, term of agreement, and annual mileage.

Lead generation from the website is important to Volvo Cars UK, so once the ideal finance quotation has been obtained, the customer can then request that this quotation be e-mailed through to their Inbox. Again, the customer can request multiple quotations if desired, with each one being compliant with the new Consumer Credit Directive rules.

Codeweavers worked closely with both Santander Consumer Finance (the supplier of the Volvo Car Financial Services products) and Autotorq (the supplier of the Volvo Cars UK website) to deliver this project. Martin Hill, Commercial Director of Codeweavers, said: “We are proud to be working with Volvo Cars UK and the rest of the project team on this exciting initiative. We are extremely confident that the new functionality will reinforce Volvo Car Financial Services as being the best way for the customer to fund their used Volvo”.

Easy to use, clear and compliant, the Mazda Used Car Locator can now allow a web customer to browse all UK dealer stock and then configure their own finance package to suit their needs. As well as enhancing the Mazda.co.uk user experience, the Codeweavers service ensures that vehicles are made affordable through Mazda Financial Services. Integrated finance calculators allow customers to specify their own PCP and Conditional Sale quotations based upon the Mazda Financial Services product rules. The customer can request as many calculations as they wish, allowing them to model different scenarios before making contact with the dealer.

Customers can also request search results by using an amazing ‘payment search‘ tool that offers customers an entirely new way of searching used car stock. This tool represents a radical departure from the traditional ‘model and derivative’ search. The monthly payment range, deposit, annual mileage and term of agreement can all be controlled by the customer, allowing them to get the most choice and value for their monthly budget.

Whether the customer searches by payment or not, the service makes it easy for the customer to take the next step and contact the dealer. The customer can request that their tailored quotation be e-mailed through to their Inbox. The customer can request multiple quotations if desired, with each one being compliant with the new Consumer Credit Directive rules – extremely useful if the customer is looking at several alternative vehicles.

Codeweavers worked closely with both Santander Consumer Finance (the supplier of the Mazda Financial Services products) and GForces (the supplier of the Mazda Motors UK website) to deliver this project. Martin Hill, Commercial Director of Codeweavers, said: “Mazda are renowned for building vehicles that exceed expectations. We are proud to have worked with Mazda Motors UK and the rest of the project team to provide a service that would reinforce this mantra, and we look forward to working with them in the future”.

Making sure that your website is compliant with the consumer credit advertising rules is probably not a priority for your business at the best of times, but recent issues surrounding the OFT’s enforcement action against Carcraft have provided evidence that the regulator will take action where it sees customers are not being treated fairly.

So I’d like to reiterate one or two major points that you should be looking for as far as consumer credit compliance on the web is concerned.
Firstly, if you intend to provide examples of monthly payments on any of your used or new vehicles, then you need to make sure that you prominently display a ‘Representative Example’ of finance. This reflects the representative finance deal for all of the finance deals displayed within an advert, and the rules clearly state that there should only be ONE representative example in each advert (or on each web page).
So are you showing a representative example? If not, you are probably breaking the law. Have you got more than one representative example on any one web page? It is highly likely that your site isn’t compliant. Of course, by not mentioning finance payments of any description you negate the need to comply with the credit advertising rules – but why would you want to do that? Surely it’s better to compliantly display the information and show how affordable your stock can be?

The content of the representative example needs to be spot on also. Items such as the rate of interest (NOT the same as the APR!) and whether that interest rate is fixed or variable will be new to most dealers – these items weren’t required until the new rules in February 2011. But they need to be there. And we haven’t even started to look at the rules surrounding how prominent the information has to be.

I have come across several instances where the new rules are beginning to be enforced by the OFT. So what exactly could ‘enforcement’ action consist of? The answer depends of course upon the severity of the breach, so it varies widely. For instance, under section 1 of the Consumer Credit Act, you are provided with a Consumer Credit Licence by the OFT. Not many dealers know that this licence can be partly or fully revoked for serious breaches of consumer credit rules. How would not being able to offer finance facilities potentially impact your business?

Also, consider the potential for harm from the resulting bad press that will inevitable follow. For instance, I wonder how many car supermarkets or used car dealers are drawing customer’s attention to the OFT reporting of Carcraft….?