Suspension Setup for 2006 Triumph Daytona 675

[caption id="" align="alignright" width="520"] Two 'old bikes' - one new to me...[/caption]

For those who don't know I love riding motorbikes and in the last couple of years have done a couple of track days but want to do a lot more.

The new bike is a 2006 Triumph Daytona 675 and so far I have been really impressed with it - even from my limited chances to push it. One thing that has been bugging me is the suspension set up. The bike was set up for a different rider so that is no surprise.

Target Sag Setup

Based on the 'ball park' suggestions from Dave Moss the target sag setup should be around 30mm on the rear and 45mm on the front. I have taken the bottom of both estimates as I am primarily riding on the road and need the travel.

Rebound is the Key

The rebound is more of a mystery to me though as only one bike I have previously owned has any options for rebound adjustment. Since I did the California superbike school course I have tried to maintain the break / turn / throttle separation rather than trailing the break. The advice from Dave is that with that style of riding faster rebound is good because you are set up to turn so I am going to dial the rebound to the suggested soft settings 7/7 front and back.

Compression Damping

Compression damping advice is a bit more tricky in a sense because even using a tie wrap to monitor the compression, the public roads are simply really rough. The most common sense advice I have heard so far is that you want to make it as soft as you can so that you use most but not all of the travel on a typical ride. This gives the suspension the best chance of soaking up the bumps in the road. Dave's advice is to go for between 2/3 and 3/4 of the way 'out' - meaning mostly soft to me. The manual suggests 8/12 respectively. Hopefully this falls into our expected range.

Now it's time to put on a tie wrap on one fork to see just how much of the travel I am using. Happy riding.


The Three P's of a Good Business Partner

There has been much written about how many co-founders are best and what the ideal number of co founders is. The bottom line is that there are lots of good reasons to do your next startup with a co-founder.

For me having a business focused co-founder is key. Don't get me wrong - I love business problems, financial modelling and have also been known to do my fair share of cold calling customers. The bottom line is that when you aren't focusing you aren't being efficient. I am definitely a subscriber to the idea that in a startup you have to spend as much time as you can doing what you are really good at as that is how you will differentiate. On the sales front it has definitely been my experience also, that in the B2B sales focusing on sales rather than marketing initially gives the best chance of success. Given that, having one founder focus on sales while the other focuses on delivering the 'stuff' seems like the perfect combination.

As well as sales performance the ideal business related co-founder to a technical co-founder can also take ownership of three other areas:

1. Product Management

Product management is a very broad role in large companies. In startups this role is even more essential and can often be lost in the other tasks spread among the founders. The benefit of having the business co-founder focus on this is that it shortens the feedback cycle from customers to product requirements.

2. Pricing and Placement

Pricing your product can be done a number of ways and it is often tempting to under-price your product. By having the business founder use market research and other factors, combined with more perspective on what the product is 'worth' to customers you get a better result. You are more likely to maximise the potential pricing of your product as well as reach the best pricing level faster.

3. Perception

One thing that I had definitely traditionally not paid enough attention to was the perception of the brand I was working on from clients. There are a few key things to consider but the old rules still apply you never get a second chance to make a first impresison. Give the business founder the resources they need to make sure that your brand is ready to sell. Invest in your website, branding, logo, social and PR. The business founder can lead on these initiative and this will give you the best chance of getting through the first six months to a year.


Schema Org Naming Frustration

Standards are a great thing but some times they lead to having to make some silly compromises. Take the schema.org event. It has a startDate field which is supposed to be a Date [note the lack of Time in the type]. It has the description The start date and time of the event, role or item (in ISO 8601 date format). - are you kidding me? Combine this with the doorTimeattribute on the same thing, Event, which is a.... you guessed it DateTime with the description The time admission will commence..

All of this would be hilarious if it wasn't that this is the 'gold standard' of resource naming. It is a pity that so many naming convention mistakes could be made in such a small space. Note that our new APIs don't have the data type in the name generally - they are called things like 'start' and always use a 'date time'. Let's see how long this convention can survive the onslaught of progressive feature expansion...


OpenHack #3

As part of trying to learn some new technology and approaches I am going to OpenHack #3 with the objective of discussing and hacking on either:

  1. Time series monitoring bucket technology for tracking readings similar to VarZ

  2. Pair with someone to learn some Ruby.

  3. Automation of Rachel builds on Raspberry Pi.

  4. Comparison of different geo-distance functions.

If you are also attending OpenHack #3 and want to pair on either of these things then come and say Hi!

-- Update

  1. Created a model for bucketz time oriented data. Added paths as well as bucket names.

  2. Registered on CoderWall

  3. Signed up for 24 Pull Requests for some inspiration on open source projects to contribute to...

Thanks for organising the event #OpenHack guys!

Travel Needs an Upgrade

Over the last year I have been working as a contract CTO and one of the clients was in the travel sector, a London based hotel chain. The client wanted to ensure that the technology was rock solid from a transactional stability point of view. Even one false payment or booking wasn't an option. (You may assume these things only happen rarely but as complexity increases so do failures.) To try and ensure that we could achieve the desired stability in light of total data centre outage applying banking style transaction management seemed a sensible place to start. This left me with a challenge; in order to deliver the project in the time scales that we needed a more 'agile' approach.

Lean / Agile Works for Start-ups but...

If you have visited many of the London start-up co-working spaces you will be familiar with the usual stack of 'Agile' and 'Lean' books that seem to litter these spaces. The challenge is how to build systems that are as stable as what you would expect after an exhaustive build and test [a'la waterfall] process. This was a particular challenge for us as we had a tiny team and needed to outsource the majority of the work. For me personally the ethos of don't out-source anything you care about was also ringing in my ears. The different back end vendors we evaluated seemed to come in two varieties:

  1. White labelling solutions who primarily offered the same solution to most clients with some re-branding.

  2. Niche agencies that offered a (sometimes) slick and customised product.

When it came to it we thought that we could do better. We wanted to apply start-up style rapid development to the back-end and out-source the front-end build to companies better placed to deliver on an industry leading solution.

Brittleness of Agile

When talking to clients they always seem to like the idea of Agile because they like to see results. From that point of view the user story generation approach to requirements capture was also something I enjoyed. User stories are a great way of capturing specific behavioural expectations.

The challenge with all of this 'speed' is, what do you put into the things that you build. There are a lot of great design patterns, like reversibility [be able to undo - encapsulating replicable components when there is a high risk of changing solution in the future] to help you out of a pinch but the hard part is still choosing where to invest your time / code. For me this is the most challenging and fascinating problem; let's assume that you only have time to write 10K lines of code - what do you want to spend them doing? Features? Tests? Integration testing?

By definition - if you are using an Agile / Lean approach then it is likely that you have to choose some things to leave out! The goal is to get your system live as soon as possible so it is up to you to pick the right things to write. For me system tests are a must as they provide the contract that guarantees that our back-end does what we say it does. After that we need some unit testing of complex logic but 100% coverage is rarely a practical goal.

To compound things further the principles of code quality and readability are exaggerated by Agile. You expect to go back to your code and modify far more frequently than you would for say a legacy system that is expected to run for years without modification. To put this into context - I wanted to engineer our platform so that we could do multiple orchestrated releases per day with system tests running in continuous integration. There are a few things you need to make sure you get right if you want to run this way:

  • Tests need to run in seconds not minutes.

  • You need to be able to run your tests on all of the different versions of your application at the same time.

  • You will probably need to be able to build multiple clusters of homogeneous servers.

  • You will probably want to run local, staged, live staged and live release clusters.

Remember: all software has bugs (feature and functional) so it is important that you set yourself up for success with the tools you need to do a 'good job' of dealing with so much uncertainty.

Detecting Issues

The big value impact for us came from the simplest things to do but all too easy to get wrong. Traceability - being able to perform detailed investigation into the root cause of an issue. This let us quickly respond to issues by being able to see a lot of detail of what was going wrong. This then drove new bugs, which had failing tests written first, which we fixed then we would release. This process became fairly fluid after a while but logging wasn't quite enough.

Again, thinking back to companies I have worked at before - one of the most useful features to build on day one is support for live site monitoring - and I don't mean TCP monitoring. Every application has a different set of indicators of health and happiness. This is often something like healthz or varz which can then be monitored by your friendly monitoring technology. For Upgrade we actually created a servlet library that made exporting stats a cinch.

Today Upgrade represents a major code base of approaching 500KLOC and can still run on a model A pi. I am proud to say that we have had only a very small number of bugs found in production. Bottom line is if you have an API write some full stack tests. You will thank yourself later.

Could Using Bleeding Edge Tech be the Best Way to Attract Talent?

It seems that the ruby language was the tool of choice if you wanted to work on the new and shiny. It may be that Ruby isn't the new shiny thing though. Like many people it has been top of my list of languages to learn for a while. The London startup scene is still heavily bought into Ruby even now. The last time I checked the 'services wanted' at Google Campus, there are a lot of calls for Ruby development. On a separate note, it is really interesting that there were no calls for 'technical co founders'; these days all you need is an app and that can be outsourced ;-)

Taking to a number of startup founders lately they have advocated using shiny new tech as a crucial part of their hiring strategy. VisualDna a previous employer also made a lot of using technology like Cassandra. But these systems too are starting to come of age. The problem with wanting to use the newest thing is that it doesn't stay new for long.

The logic seems to go that by concentrating on newer technology you are more likely to find self starter employees who makes learning new skills part of his regular work. This strategy makes a lot of sense. There are a few potential issues:

  • Pre-qualify your recruits on a smaller market of real zealot.

  • You have to try and figure out who is 'learning' and who is 'earning'.

  • Admiration is the furthest from understanding: it can be very hard to know when a recruit is simply following others ideas or practice.

If you want to work with startups today it seems like the main languages are Ruby for web, Java for android and Objective C for iphone. The exception is the data science scene where the challenges of handling the ever increasing challenges of automating large data set processing in real time is still resulting in some language innovation.