Jekyll2019-08-17T20:28:59+00:00https://blog.flurdy.com/feed.xmlIvar’s ramblingThe ramblings of Ivar Abrahamsen at flurdy.com. Contain ideas, ranting at innocents, blinkered sporting opinions, tech bable, and probably not enough to be interesting.All the eggs in one basket2019-06-18T01:01:00+00:002019-06-18T01:01:00+00:00https://blog.flurdy.com/2019/06/all-eggs-in-one-cloud-basket<p>Many companies have all or most of their infrastructure with just one cloud provider.
That does have some benefits, but also some drawbacks and serious risks.</p>
<ul>
<li>What are these benefits of using only one cloud provider?</li>
<li>What are the reasons people end up with just one cloud?</li>
<li>What are the risks and drawbacks of putting all your eggs in one cloud basket?</li>
<li>And what are the alternatives and steps to reduce the risk?</li>
</ul>
<h2 id="all-in-the-cloud">All in the cloud</h2>
<p>Since <a href="https://aws.amazon.com">Amazon’s AWS</a> was launched, followed by <a href="https://cloud.google.com">Google’s GCP</a>, <a href="https://digitalocean.com">Digital Ocean</a>, <a href="https://azure.microsoft.com">Microsoft’s Azure</a>, <a href="https://heroku.com">Heroku</a> and many, many more, the term <em>cloud</em> has become a common well understood term for hosting infrastructure.</p>
<p>And from initially being a bit hesitant and just trying it out many companies have now moved most of their infrastructure to <em>the cloud</em>. Especially younger smaller companies with less legacy datacentre usage.</p>
<p>Starting a new company or project using co-location datacentre servers just does not make sense any more unless you are on a real shoestring budget where the flexibility and speed of a cloud solution is not possible.</p>
<h2 id="stay-with-the-one-cloud">Stay with the one cloud</h2>
<p>AWS was the first real cloud provider. There was others before depending on how you define <em>cloud</em> but none came with the size, marketing, and total <a href="https://en.wikipedia.org/wiki/Infrastructure_as_a_service">IAAS</a> solution of AWS. So AWS was the first provider most people dabbled with. And by now 10+ years later it is the giant in this marketplace with as many customers as all the others combined. And with a huge range of features to confuse the best of us.</p>
<p>And since companies was already on AWS many have not really looked further at other cloud providers.</p>
<p>The same happens with newer companies and projects that perhaps choose other big providers such as GCP or Azure.
Once they are on and it works they do not look further as their chosen cloud provider does everything they need.</p>
<p>If you only use one provider your employees can specialise and enhance their skills of its specific features.</p>
<h2 id="cloud-lock-in">Cloud lock-in</h2>
<p>The cloud providers also encourage people not to look elsewhere. As mentioned they provide a lot of IAAS features and continually add more so your requirements are mostly met on the one platform.</p>
<p>They provider services that are unique to their platform.
Such as <a href="https://aws.amazon.com/lambda">AWS’s Lamda</a> or <a href="https://cloud.google.com/functions/">GCP’s Cloud Functions</a>
Or database solutions and data that are not easily transferrable such as <a href="https://aws.amazon.com/dynamodb/">Dynamo</a> or <a href="https://cloud.google.com/spanner/">Cloud Spanner</a>.</p>
<p>But mostly they try to spread as wide as possible and ingrate as deep as possible into your whole organisation and procedures so that a migration elsewhere will be very painful and just not feasible.</p>
<p><a href="https://en.wikipedia.org/wiki/File:Jean_Baptiste_Creuze_Broken_Eggs.JPG"><img src="/img/posts/2019/06/baptiste-broken-eggs-small.jpg" alt="Broken eggs" /></a></p>
<p><em><a href="https://en.wikipedia.org/wiki/File:Jean_Baptiste_Creuze_Broken_Eggs.JPG">Painting by Jean Baptiste. Public Domain</a></em></p>
<h1 id="smashed-eggs">Smashed eggs</h1>
<p>Having all your eggs in one basket is risky.</p>
<p>If all your infrastructure is in the cloud and with just one provider you run the risk of several things crippling your project or whole company.</p>
<h2 id="runaway-usage-equals-costs">Runaway usage equals costs</h2>
<p>Setting up and using a cloud service is fast, easy and very contagious.</p>
<p>The old way of rack based bare metal co-location flow of ordering a new server then setting it up was time consuming, very time consuming, perhaps days if not weeks. A cloud instance is matter of minutes or less.</p>
<p>Virtual server solutions, e.g. Zen, VMWare, made this process quicker, but still painful and people were frugal with how often they created a new server.</p>
<p>With cloud solutions they are not, and they expand to use more and more storage, databases, queues, and more that are metred costs.
When this infects your whole business the usage continues to escalate enormously, control and oversight evaporates and the costs rocket.</p>
<h2 id="downtime">Downtime</h2>
<p>A big risk that bleeds money is downtime.
When your service is offline you loose money. A lot of money.</p>
<p>And big cloud providers do go down, taking your services with them offline.</p>
<p>AWS has had issues many times,
GCP has been offline,
and Azure is also known for significant downtime.</p>
<p>Some times it is not just a partial outage nor limited to a region, sometimes everything goes offline.
For example <a href="https://techcrunch.com/2019/06/02/google-cloud-is-down-affecting-numerous-applications-and-services/">GCP’s recent massive outage</a> that took also down Google’s own Youtube, GMail and more.</p>
<p>And when they are down there is not much you can do than wait.
Hopefully they are good at communicating the status.</p>
<h2 id="automated-suspensions-and-collateral-damage">Automated suspensions and collateral damage</h2>
<p>The large cloud providers due to their scale has mostly automated a lot of their procedures.
Including detection of illegal activity, abuse reporting and support.
And at best have staff on low pay whom have to process a huge amount of tickets by spending as little time on per ticket as possible.</p>
<p>I have been scared by numerous reports of random accounts being frozen and service taken offline for no apparent reason.
Or tiny misinterpretations that would have been corrected have they been able to talk to a human.</p>
<p>But I was suffering from <a href="https://encyclopedia.ushmm.org/content/en/article/martin-niemoeller-first-they-came-for-the-socialists">Niemöller’s quote</a>: “<em>First they came for the socialists, and I did not speak out — because I was not a socialist…</em>” I did not think I was doing anything wrong so this did not involve me.</p>
<p>Until last year, when my own <a href="https://ads.google.com">Adwords</a> account was suspended then banned for no apparent reason with no recourse.
Thankfully they did not suspend any of my other accounts or use of other Google services as that would affect not just me badly but my family as well.</p>
<p>Google have done that to <a href="https://twitter.com/search?q=google%20account%20suspended">others</a>, e.g. suspended all accounts linked and just suspected of being linked, including business and personal accounts. And total ban ie deleting <a href="https://slate.com/technology/2013/04/life-without-google-when-my-account-was-suspended-i-felt-like-id-been-dumped.html">docs, email, photos, Android profiles</a> for all these accounts.
They do state that they may do so in their policies.</p>
<p>Recently Digital Ocean had some bad PR when one their automated abuse script <a href="https://twitter.com/w3Nicolas/status/1134529316904153089">banned a persons account effectively taking his whole company offline</a>.
What made it worse he no longer could access his database backups as they were all hosted with DO.
So his company was effectively dead.
Thankfully he had enough social media clout to reach one of DO’s founders whom rectified the problem.
Most people don’t have that reach.</p>
<p>These stories have made me very wary of ever relying on one provider again.</p>
<p><a href="https://www.flickr.com/photos/artembali/44927194462"><img src="/img/posts/2019/06/battery-chicken-small.jpg" alt="Battery chicken" /></a></p>
<p><em><a href="https://www.flickr.com/photos/artembali/44927194462">Photo by Artem Beliaikin. Public domain</a></em></p>
<h1 id="better-egg-distribution">Better egg distribution</h1>
<p>So what steps can we take to minimise the risk of depending on a single cloud provider?</p>
<h2 id="cost-monitoring">Cost monitoring</h2>
<p>You should keep a close look on how much your company is spending on a cloud.
And if steps need to be taken to reduce it or just slow it down, or detect any anomalies.</p>
<p>The providers offer monitoring, e.g. <a href="https://aws.amazon.com/cloudwatch/">CloudWatch</a> and <a href="https://cloud.google.com/monitoring/">StackDriver</a>.</p>
<p>And there is a vast range of 3rd party tools to monitor usage, threats, errors and billing costs across several cloud providers.
Such as <a href="https://www.dynatrace.com">Dynatrace</a>, <a href="https://looker.com">Looker</a>, <a href="https://www.datadoghq.com">Datadog</a>, <a href="https://newrelic.com">NewRelic</a>, <a href="https://www.cloudability.com">Cloudability</a>, <a href="https://www.alertlogic.com">AlertLogic</a>, <a href="https://www.cloudhealthtech.com">CloudHealth</a> etc.</p>
<p>Though to me they all seems one tiny AWS feature announcement away from going out of business.</p>
<p>But its a lucrative marked and <a href="https://techcrunch.com/2019/06/06/google-to-acquire-analytics-startup-looker-for-2-6-billion/">Looker was just acquired by Google</a>.</p>
<h2 id="availability-zones-and-regions">Availability zones and regions</h2>
<p>Most of the cloud provider downtimes are due to a single datacentre of theirs going offline for some reason. Power cut, builders accidentally digging through a cable outside, etc.
So only customers using that single datacentre are affected.</p>
<p>So the cloud providers all offer availability zones and multiple regions to mitigate this risk.</p>
<p>Availability zones are multiple datacentres in the same city but not the same building.
Which reduces the risk of a physical problem at a single building.</p>
<p>Regions are datacentre locations spread across the globe.
With possibly its own multiple availability zones per site.
This reduces the risk of a larger city wide problem.</p>
<p>If you modify and design your applications and infrastructure to spread horizontally across the zones and/or regions,
you can survive when a providers single datacentre goes down.</p>
<p>This horizontally scalable design costs a lot architecture and development time and runtime resources so there is a clear overhead. But you can sleep more easily.</p>
<p>However as mentioned if there is a problem with some specific cloud features it may take down all the zones and global regions of that provider. They are rare but they do happen.</p>
<h2 id="many-different-baskets-hybrid">Many different baskets, hybrid</h2>
<p>Of course the obvious solution to one basket is many baskets.
Use several cloud providers, and your own hosted solutions.</p>
<p>This is a <em>hybrid</em> solution, and many providers and 3rd parties offering solutions for this.
AWS offer an integration with VMWare for an on-premises solution, <a href="https://aws.amazon.com/outposts/">Outpost</a>, that integrates with AWS.
Google is offering several tools to manage Hybrid solutions, e.g. (<a href="https://cloud.google.com/anthos/">Anthos</a>).
But I am suspicious of these, I am not sure what the motives are for their offering,
but I am sure it is to drive more use of their own cloud.</p>
<p>Some 3rd parties offer a layer on top that is supposed to <em>smoothly</em> uses different cloud providers underneath.
That may work, but I am also not sold on the idea of introducing yet another component.
Those I have used are OK but just added more ambiguity and less flexibility.</p>
<p>You can architect your applications yourself to cater to work across multiple cloud providers.
This is the best solution if a full hybrid solution is desired.</p>
<p>You really have to consider eventual consistence and temporary separated and then rejoined clusters.
My take is to only do this if you have a big budget, a mature product, and very skilled architecture and ops teams.
Most of the time this is a complete overkill.</p>
<h2 id="independent-technology">Independent technology</h2>
<p>My main opinion on hardened cloud usage is to use independent technology.
Use technology stacks that you can use on any cloud provider.
And minimise proprietary technology a cloud provider supplies.</p>
<p>For instance using <a href="https://kubernetes.io">Kubernetes</a> lets you deploy your solution to many providers.
You can run it across their instances, or use their managed services such as <a href="https://aws.amazon.com/eks/">EKS</a>, <a href="https://cloud.google.com/kubernetes-engine/">GKE</a>, <a href="https://azure.microsoft.com/en-us/services/kubernetes-service/">AKS</a> and with <a href="https://www.digitalocean.com/products/kubernetes/">DigitalOcean</a>.
Though Kubernetes is a behemoth and not right for everyone.</p>
<p>For databases use <a href="https://www.postgresql.org">Postgres</a>, <a href="https://redis.io">Redis</a>, <a href="http://cassandra.apache.org">Cassandra</a>, <a href="https://www.cockroachlabs.com">CockroachDB</a> and others that
you can use on any provider and does not tie your data to a specific supplier.</p>
<p>Use <a href="https://www.elastic.co/elk-stack">EKL</a> logging so that it is ambiguous if you use AWS or GCP or others.</p>
<p>There are also many generic serverless functions solutions.
<a href="https://serverless.com/">Serverless</a>, <a href="https://fission.io/">Fission</a>, <a href="https://www.openfaas.com/">OpenFAAS</a>,
and I am sure many more to come.
I have not tested them well enough to know if they are mature enough yet.</p>
<p>To avoid reinventing the wheel, and use the cloud providers automatic scaling ability,
I understand people choosing the cloud providers databases and streaming solutions instead of setting up and maintaining all that infrastructure yourself.
My projects have often relied on DynamoDB or <a href="https://aws.amazon.com/rds/">AWS’s RDS</a>, and I would consider <a href="https://aws.amazon.com/msk/">AWS’s Kafka service</a> in future projects.
So my suggestion is not 100% gospel, just be pragmatic and responsible.</p>
<h2 id="back-up-for-total-dataloss">Back up for total dataloss</h2>
<p>Always have full back up of your data, and fully restore tested, that is not only stored on your cloud provider.</p>
<p>It does not have to be real time slave of the data but a fairly recent full back up.
So that in case of total dataloss that may happen if your account is hacked, your account is suspended, or other issues, you can still restore your database to a fairly recent state.</p>
<p>That way your company and project is not dead, just very set back.</p>
<p><a href="https://pixabay.com/photos/fried-buffet-gastronomy-hotel-1789962/"><img src="/img/posts/2019/06/fried-egg-small.jpg" alt="Fried egg buffet" /></a></p>
<p><em><a href="https://pixabay.com/users/darf_nicht_mehr_hochladen-2998623/">Photo by darf_nicht_mehr_hochladen from Pixabay. Public Domain</a></em></p>
<h1 id="my-fried-eggs">My fried eggs</h1>
<p>So what do I actually suggest for companies cloud strategy?</p>
<p>Plan, plan, try, plan, plan.</p>
<ul>
<li>Be aware of the risks of relying on one provider</li>
<li>Plan for sudden migration</li>
<li>Implement full back up procedures</li>
<li>Test out other providers</li>
<li>Use mostly independent technologies</li>
</ul>
<p>Essentially plan and document a migration.
But you don’t always have to implement a full hybrid solution as that can be expensive.</p>
<p>But do try out other providers.
Perhaps run small quite independent applications on GCP if your main stack is on AWS for example.
That way the ramp up and teething problems of using another provider can be dealt with already if a migration is needed.</p>
<p>Do trial run migration if you want to wash out any possible hidden gotchas on your reliance of the current provider.</p>
<p>And run as much of an independent technology stack as possible.</p>
<p>You can and perhaps should use their very scalable database and streaming solutions
for any high throughput parts of your architecture.
But do back it up and have tested migration plan to another solution in place.</p>
<p>Feel free to try out Lamda and similar services, but try to limit its core importance.
I.e. can it be replaced quickly.</p>
<h2 id="budget-cloud-independence">Budget cloud independence</h2>
<p>An important step often missed by plans to move to a cloud provider is to include a budget to move away from it.</p>
<p>I know it sounds like a hard sell to your CTO that you are already thinking of moving away from the shiny chosen cloud provider,
but it is essential in a costing plan of a bid/project that you will have to consider moving away from it as well.</p>
<p>But I am softening up on this requirement to instead include budgets to plan a migration and test other providers, and not budget for a full migration.</p>
<p><a href="https://www.flickr.com/photos/53344659@N05/4978438263"><img src="/img/posts/2019/06/egg-chick-small.jpg" alt="Chick and eggs" /></a></p>
<p><em><a href="https://www.flickr.com/photos/53344659@N05/4978438263">Photo by sheilapic76. CC-by</a></em></p>
<h1 id="any-basket-is-better-than-broken-eggs">Any basket is better than broken eggs</h1>
<p>Should all companies running on only one cloud provider follow my advice?</p>
<p>No, for most putting all eggs in one basket is calculated risk worth taking.</p>
<p>After all, <em>A</em> cloud provider is better than none.</p>
<p>And remember the big providers are much better at reliability, fault tolerance and networking than you.
Yes, a lot better.</p>
<p>Just please consider my suggestion of planning and testing alternatives if you can afford it.
Or rather can you afford not to?</p>flurdyMany companies have all or most of their infrastructure with just one cloud provider. That does have some benefits, but also some drawbacks and serious risks.To PAAS or not to PAAS2019-04-07T21:22:00+00:002019-04-07T21:22:00+00:00https://blog.flurdy.com/2019/04/to-paas-or-not-to-paas<h2 id="when-is-a-paas-the-right-tool">When is a PAAS the right tool?</h2>
<ul>
<li>Who should use it? Who should not?</li>
<li>Who can afford it? For whom is it too expensive?</li>
<li>Who will benefit? Where will it be restrictive?</li>
<li>and When?</li>
</ul>
<p>I have read, heard and seen many tales and blog posts on how to move away from a PAAS.
But those are just information on how to and not why.
And they were suitable for that organisation for their requirements at that specific time, not always.</p>
<p>I hope to clarify that a PAAS is great for many people/companies.
And sometimes not.</p>
<h2 id="what-is-a-paas">What is a PAAS</h2>
<p><a href="https://en.wikipedia.org/wiki/Platform_as_a_service">PAAS = Platform As A Service</a>.</p>
<p>It is a service where you deploy and host your application
without having to consider any infrastructure.</p>
<ul>
<li>You do not need to think about creating or setting up a server instance(s).</li>
<li>You do not need to consider any storage or networking.</li>
<li>You do not need to worry about OS updates and security patches.</li>
<li>You do not need to configure load balancing.</li>
<li>And much much more.</li>
</ul>
<p>Well known PAASes are <a href="http://heroku.com">Heroku</a>, <a href="https://cloud.google.com/appengine/">AppEngine</a> and <a href="https://aws.amazon.com/lightsail/">AWS Lightsail</a>. As well as many more specific tailored towards a niche, for example programming languages such as <a href="https://www.ruby-lang.org/en/">Ruby</a>, etc.</p>
<p>Unlike a vanilla cloud offering i.e. an IAAS, <a href="https://aws.amazon.com/lightsail/">Infrastructure As A Service</a>,
where you do have to consider all these steps yourself.
Well known IAASes are <a href="https://aws.amazon.com/ec2/">AWS EC2</a>, <a href="https://cloud.google.com">GCP</a> and <a href="https://azure.microsoft.com">Azure</a>.</p>
<p>There are also many ways you can host a PAAS yourself on your own IAAS or bare metal servers.
Such as <a href="https://www.cloudfoundry.org/">Cloud Foundry</a>, <a href="https://www.openshift.com/">OpenShift</a> or <a href="http://dokku.viewdocs.io/dokku/">Dokku</a>.</p>
<h2 id="why-not-paas">Why not PAAS</h2>
<p>Why are people complaining of PAAS offerings?</p>
<p>Some complaints are valid, many invalid.</p>
<ul>
<li>Cost</li>
<li>Inflexibility</li>
<li>Ownership</li>
</ul>
<p>The lack of flexibility is what developers and operations would moan about PAAS.
People like to tinker and be in control.
Connect this app to that database.
Triple the memory on that instance,
scale that application to 4 nodes,
bundle these three apps on one instance,
restrict the firewall on these etc.</p>
<p>The cost is what whomever pays the bill would moan about the most.
If handled incorrectly a PAAS can be costly,
especially if naïvely compared to pure hosting costs of an IAAS.</p>
<p>Ownership. People may think with the inflexibility and black-box nature of a PAAS,
that they don’t know what is going on.
Who can see my company’s data, my users’ requests?
Is there a legal risk?</p>
<h2 id="paas-is-just-hosting-right">PAAS is just hosting, right?</h2>
<p>Often people think of PAAS as a straight swap of the instances in a standard cloud offering (IAAS).
And compare the costs and flexibility of that only.
But a PAAS is so much more, and that is why it costs so much more <em>per instance</em>.</p>
<p>A PAAS offers logging, metrics, backup, load balancing, redundancy, roll-back, deployment, scaling, patching, etc,
as part of the one price offering.</p>
<p>It offers years of experience, tweaking, to make the services that provide all that to work as smooth as possible, all the time, for everyone.</p>
<p>And when there is a network issue they take care of it immediately.
Any hardware issue they take care of it.
Any security patches - they apply it for you.
Most of the time you wont even notice as they bring up another horizontal node of your application and replace your current one without any downtime.</p>
<p>And for instance in the case of Heroku they offer <a href="https://elements.heroku.com/addons/">lots of add-ons</a> that is mostly just one click or one CLI command away to be set up and working straight away with your applications.</p>
<h2 id="time-is-money">Time is money</h2>
<p>With a self hosted IAAS solution on a cloud provider, you have to pay for all the time, i.e. salaries,
for people to investigate, set up, fail, retry, manage, maintain, upgrade and more
of all your server instances and applications. Every time. All the time.</p>
<p>That is expensive.</p>
<p>And to be on-call when it all falls over in the middle of the night.</p>
<h2 id="is-paas-expensive">Is PAAS expensive?</h2>
<!-- ( *Ignoring the free and $7 per month price bands that for example Heroku has, as they are more suitable for personal projects and prototypes.* ) -->
<p>For businesses prices at for example Heroku start at $25 per month.</p>
<p>That is cheap.</p>
<p>Some will counter that you can get a nano instance at AWS for a month for a lot less.
But they forget the above mentioned, PAAS is not just hosting.</p>
<p>For a company $25 per month is nothing.
The more powerful options at $50 or even $250 for a real business is still nothing,
even if horizontally scaled to multiple nodes,
if the applications are important to the company.</p>
<p>Remember you are comparing it to paying for more salaries in a custom infrastructure.
Or divert focus away from other tasks for your Operations staff.</p>
<p>Remember $25 cost would comparably pay for perhaps 20 minutes or less for an Ops contractor when comparing hourly contractor rates if in e.g. London.</p>
<p>So no, PAAS is cheap, not expensive.</p>
<p>However once you scale to <em>a lot</em> of apps and nodes, and a lot of traffic on AppEngine for example,
PAAS is then no longer the most economical solution.
Though at that scale, nothing is cheap.</p>
<h2 id="premature-optimisation">Premature optimisation</h2>
<p>One thing a PAAS is good for is to prove whether a project/application need heavy infrastructure investment before you commit to it.</p>
<p>Try lots of ideas, pivots, applications in a live environment before focussing on one that will succeed.</p>
<p>Prove that it is useful and will be worth the return of investment before spending time and money into salaries, tools and IAAS to set up an infrastructure that scales for a big success.</p>
<p>Validate the idea, not infrastructure that may not be needed.</p>
<h2 id="one-size-fits-no-one">One size fits no-one</h2>
<p>The requirements, time and money available is very different depending on your situation:</p>
<h4 id="startup-">Startup <i class="icon ion-md-checkmark-circle glyp-green"></i></h4>
<p>A Startup is often a good candidate for a PAAS project.</p>
<p>A Startup may want to focus on validating the idea, avoiding the above mention premature optimisation.
Often they have limited budget and need to focus on a few areas only, of which infrastructure probably is not yet included.</p>
<p>A Startup is often time poor, needing to get something launched before anyone else do the same.</p>
<p>If the product starts to make profit then they can start to diversify the PAAS into custom infrastructure architecture(s).</p>
<h4 id="unicorn-startup-">Unicorn Startup <i class="icon ion-md-close-circle glyp-red"></i></h4>
<p>A Startup with big investments and in the process of massively scaling its staff may be able to hire a boat load of Operations employees to create an elaborate architecture and infrastructure.</p>
<h4 id="no-opsdevops-">No Ops/DevOps <i class="icon ion-md-checkmark-circle glyp-green"></i></h4>
<p>If you are a small company that do not want to hire Operations staff then having your application / website on a PAAS makes sense,
they do the majority of the Ops for you.</p>
<h4 id="cheap-labour-cost--">Cheap labour cost <i class="icon ion-md-close-circle glyp-red"></i></h4>
<p>In a cheaper labour location your company may see benefits in
paying salaries to set up and maintain a custom infrastructure, as a PAAS is then probably not an economical choice.</p>
<h4 id="new-greenfield-project-">New greenfield project <i class="icon ion-md-close-circle glyp-red"></i></h4>
<p>A new greenfield project in a larger organisation often have both the funding and time to go full wack on custom infrastructure.</p>
<h4 id="prototyping-">Prototyping <i class="icon ion-md-checkmark-circle glyp-green"></i></h4>
<p>Prototyping is an ideal PAAS candidate.</p>
<p>For some it is very useful as just a simple UX scaffold to demonstrate a project idea.
For others it would make sense as a way of iterating over a full version but still not properly launched.</p>
<h4 id="live-asap-">Live ASAP <i class="icon ion-md-checkmark-circle glyp-green"></i></h4>
<p>If you need the get a live version straight away, it may make sense to deploy it to a PAAS first.
Then iterate on a more elaborate custom infrastructure whilst you already at the same have a live site.</p>
<h4 id="monolith-">Monolith <i class="icon ion-md-checkmark-circle glyp-green"></i></h4>
<p>If the app is a fairly self contained monolithic application a PAAS can be a good option.</p>
<h4 id="microservices-">Microservices <i class="icon ion-md-close-circle glyp-red"></i></h4>
<p>An ant farm myriad of a <a href="https://en.wikipedia.org/wiki/Microservices">microservices architecture</a> would be a bad choice for a PAAS.</p>
<h4 id="support-tools-">Support tools <i class="icon ion-md-checkmark-circle glyp-green"></i></h4>
<p>Simple internal tools may also be a good PAAS candidate.
They often don’t require the full customer facing capacity and reliability.</p>
<h4 id="offshoot--skunkworks--">Offshoot / Skunkworks <i class="icon ion-md-checkmark-circle glyp-green"></i></h4>
<p>If there is a project or department that is separated from the rest you may not want it to run on your normal hosting solution.
For those a PAAS might make sense.
And later be rolled into the corporate infrastructure if the project itself becomes integrated.</p>
<h4 id="personal-project-">Personal project <i class="icon ion-md-checkmark-circle glyp-green"></i></h4>
<p>A PAAS is ideal for hobby projects.
Something that normally can be on one node, with few visitors, and low resource requirements.
It may have a database but that is about it.</p>
<p>And many PAAS providers such as Heroku offers free hosting for low usage applications.</p>
<h4 id="lost-of-personal-projects--">Lost of personal projects <i class="icon ion-md-close-circle glyp-red"></i></h4>
<p>However if you have a lot of personal projects, and over time you will,
you will exceed some free band restrictions with some PAAS providers.</p>
<p>For instance Heroku offers <a href="https://devcenter.heroku.com/articles/free-dyno-hours">1000 free hours</a>,
across all your applications combined.</p>
<p>And whilst most of your inactive apps will sleep often,
with enough apps, especially if some are hit often by e.g. Google search bots,
then you will quickly exceed that limit.</p>
<p>Then you will have to like me move some of the apps to another solution.</p>
<h4 id="search-ranking-with-free-pricing-">Search ranking with free pricing <i class="icon ion-md-close-circle glyp-red"></i></h4>
<p>Note if you use a PAAS providers free offering which uses a <em>sleep</em> feature,
then you will experience slow response times when a request awakes it.</p>
<p>This affects search rankings, and user experience.</p>
<h4 id="resource-demanding-application-">Resource demanding application <i class="icon ion-md-close-circle glyp-red"></i></h4>
<p>If your application demands a lot of processing power, or memory then a PAAS
might not be suitable.</p>
<p>PAASes often provides a limited node for free. E.g. 512mb with Heroku.
And then offer more powerful nodes at a much higher price point.</p>
<h4 id="core-business-">Core business <i class="icon ion-md-close-circle glyp-red"></i></h4>
<p>If the application is your core business,
and you are making a profit,
then perhaps you should scale it out and invest in a custom infrastructure that perfectly suits your bespoke needs.</p>
<h2 id="what-about-kubernetes">What about Kubernetes</h2>
<p><a href="https://kubernetes.io">Kubernetes</a>,
is the current big pink elephant in the room.
The 300 pound gorilla.
Whichever analogy I can wrongly apply, Kubernetes is very popular at the moment and relevant to a PAAS consideration.</p>
<p>I am a heavy Kubernetes user myself. I have written some <a href="http://flurdy.com/docs/kubernetes/kubernetes-101.html">introduction to Kubernetes</a> docs on <a href="https://flurdy.com">flurdy.com</a> that may be helpful.</p>
<p>Kubernetes bridges some of the gap between a pure IAAS and a PAAS. But it still requires significant time investment in training, configuration and normal operations monitoring and maintenance. And Kubernetes is very expensive as you end up running quite a few high memory nodes, with extra load balancers etc.</p>
<p>Kubernetes is vast and complicated, with a large surface area of where it could go wrong. So it is not suitable for all, in every situation, all the time.</p>
<h2 id="so-to-paas-or-not-to-paas">So, to PAAS or not to PAAS?</h2>
<p>It depends.</p>
<p>For a new project I would suggest just to initially throw it up on a PAAS.
And not the free options, a proper supported <em>business</em> node.</p>
<p>Validate it, iterate, then if it makes sense due to popularity or company policy move it to a custom infrastructure. And for that I would suggest Kubernetes.</p>
<p>For any prototyping, just use a PAAS.</p>
<p>For a large project I would suggest Kubernetes if you do not need to go live immediately. Especially if it ends up as multiple applications.</p>flurdyWhen is a PAAS the right tool?Blog quick. Blog now!2019-03-17T14:30:00+00:002019-03-17T14:30:00+00:00https://blog.flurdy.com/2019/03/blog-quick-blog-now<h3 id="do-it-quick">Do it quick</h3>
<p>When you start a blog post, do it quick. Publish as soon as possible.</p>
<h3 id="where-blog-ideas-goes-to-die">Where blog ideas goes to die</h3>
<p>I have used <a href="https://docs.google.com">Google Docs</a> as a place to draft blog ideas.
Over the years I have a accumulated <strong><em>a lot</em></strong> of unfinished blog idea documents that never have and never will be posted.</p>
<p>Some are just one liners. The brief idea of a possible blog posts.</p>
<p>Some are more extensive with a few paragraphs, and some outline plans for the blog post.</p>
<p>Some have been redited a few times of the years with different view points in the same draft.</p>
<p>And they all are extremely unlikely to ever be finished and published on <a href="https://blog.flurdy.com">my blog</a>.</p>
<p>Why? Because of time.</p>
<h3 id="time-limited">Time limited</h3>
<p>Why? Because ideas are relevant to now, the time when you have the idea, the inspiration, the point of view that will be published in that blog post.</p>
<h4 id="inspiration-wane">Inspiration wane</h4>
<p>Certainly my inspiration to write a specific posts wanes over time.</p>
<p>If I had been hurt or frustrated by something,
that pain will heal a bit
and any irritation will wither and feel less important.</p>
<p>If something has inspired me or made me laugh,
that will be less funny or powerful as time moves on.</p>
<h4 id="priorities-changes">Priorities changes</h4>
<p>If I have just come up with an idea to solve a problem,
over time my desire to solve that may change.</p>
<p>Maybe it is no longer a problem,
maybe it no longer hurts nor cheer me up.</p>
<p>Maybe I have found other solutions.</p>
<p>Maybe I don’t have time to write something that I no longer think is that important any more.</p>
<h4 id="poor-memory">Poor memory</h4>
<p>Also over time some ideas, frustration, solutions are simply forgotten.
Or at least the details to make it worth writing a blog post.</p>
<p>Or embarrassing as I no longer am sure where and from whom I could attribute the original idea to.</p>
<h4 id="point-of-view-changes">Point of view changes</h4>
<p>Another important point is that my point of view changes over time.</p>
<p>I may have experienced other ideas, tools, solutions, etc that may work better,
or experienced that what I was writing about does not work well.</p>
<p>Or as mentioned above I feel less passionate about it.</p>
<p>I have noticed that in several of the longer long-lived non-published blog drafts,
that they often seem to contain different views in different parts of the drafts.
And have been rewritten several times.</p>
<p>When reading those drafts they would be a poor blog post.
The start may lean towards one point of view,
but the end seems to have another. Not very coherent.</p>
<h4 id="not-fresh-technology-or-process">Not fresh technology or process</h4>
<p>And sometimes the blog idea was related to a new piece of technology,
or new process or method I have just learned from colleagues or a conference.</p>
<p>And these may start to feel stale. Newer technologies may have replaced it.
Better processes may have been born to replace it.</p>
<p>Or they are now too well established so a blog posts would feel like preaching to the choir.</p>
<h3 id="blog-quick">Blog quick</h3>
<p>So my solution these days is to blog quick.</p>
<p>Write and publish it whilst the idea is fresh,
the passion is high,
and points of view does not change.</p>
<h4 id="publish-drafts">Publish drafts</h4>
<p>I try with the blog posts, and the howto articles on my
<a href="https://flurdy.com">flurdy.com</a> site,
to publish drafts live if they more or less covering most points.</p>
<p>With typos and missing minor sections.</p>
<h4 id="edit-live-posts">Edit live posts</h4>
<p>Then I quickly edit and tweak it whilst continuing to publish the changes.</p>
<p>I guess that inspires me to focus and make sure it is finish, and quickly.
Before anyone notices.</p>
<h3 id="better-blog">Better blog</h3>
<p>I think these also leans to better quality blog posts.
As they are focussed, not over elaboration, not over polished.
More to the point, with less cruft.</p>
<h4 id="more-blog-posts">More blog posts</h4>
<p>This hopefully encourages people to write more blog posts.
There is less barrier to write a post,
less guilt over drafts living on forever.</p>
<p>Just brain storm, quick typo and polish, and done. And move on in life.</p>
<h4 id="brain-dump">Brain dump</h4>
<p>I do remember a university lecturer of mine advising us all
to prevent any writers block, at the start of any assignments etc,
to first of all just brain dump for 20 minutes.</p>
<p>Just write down anything you think of related to the assignment.
Don’t think, don’t doubt, just dump it onto the keyboard.</p>
<p>Then you can split, move, delete the sentences afterwards as it will be lot easier to continue then.
And in todays computer world as opposed to the old type/letter writing days this works well.</p>
<h4 id="tweets">Tweets</h4>
<p>Most of my one liner ideas are now pushed onto <a href="https://twitter.com/flurdy">my twitter feed</a> instead.
Throw it out there to my poor followers as a raw idea.
If it is good I can build upon the 140 characters into a blog posts.</p>
<h3 id="not-just-blog-posts">Not just blog posts</h3>
<p>I think these concepts are probably well known.
And not limited to blog posts.</p>
<p>It obviously also works with projects, chores,
and other ideas and tasks that need focus and
especially those where an early brain dump onto paper/screen can help.</p>
<h4 id="where-project-ideas-goes-to-die">Where project ideas goes to die</h4>
<p>I have many project ideas at <a href="https://code.flurdy.com">code.flurdy.com</a>.
But most of the older ideas will never be touched.</p>
<p>If I have an idea for a project,
I must do it now, and do it quick.</p>
<p>Make a <a href="https://www.agilealliance.org/glossary/mvp/">MVP</a> quickly.
Throw it out there.
Iterate over it for a little.
Make it useful.
Then move on to the next idea.</p>
<p>Most of my older ideas are no longer important to me.</p>
<h3 id="disagree-with-old-posts">Disagree with old posts</h3>
<p>As my points of view changes over the years,
I now disagree with many (nearly all) of
my older blog posts.</p>
<p>But they show what I thought at the time and I am proud of them,
so removing them makes no sense.</p>
<p>Though it is annoying when people ask (or worse just assume)
<strong><em>“why do I today think X is so bad/good”</em></strong>?
When it may be 5 or 10 years since I thought so.
And then maybe only for a very brief point in time.</p>
<p>So no, I no longer think Jira is great, nor that Spring and Java is fantastic, nor that <a href="/2009/01/dont-like-scrum-but-will-not-use.html">I will never touch Scrum</a>.</p>
<p>In 5 years from now I may think simple task boards and <a href="https://ronjeffries.com/xprog/articles/the-noestimates-movement/">no estimates</a> to be stupid. That <a href="">Rust</a> never was a good idea. That lean, pairing, <a href="https://en.wikipedia.org/wiki/Mob_programming">mobbing</a> all proved to be costly. Who knows.</p>
<h3 id="blog-now">Blog Now</h3>
<p>So don’t hold back, if you think of an idea - blog it quick.
And don’t postpone - blog now.</p>flurdyDo it quickMigrate blog to Jekyll2019-02-22T23:10:00+00:002019-02-22T23:10:00+00:00https://blog.flurdy.com/2019/02/migrate-blog-to-jekyll<p>In <a href="/2019/02/migrating-blog-away-from-blogger.html">my previous post</a> I explained why I decided to migrate <a href="http://blog.flurdy.com">my blog</a> away from <a href="http://blogger.com">Blogger</a>.
And that I decided to use <a href="http://jekyllrb.com">Jekyll</a> to generate my blog from now on.</p>
<h3 id="what-is-jekyll">What is Jekyll</h3>
<p>Jekyll is a Ruby based website generator.
Its output is static html pages that you can include with whatever web server you choose, including Jekyll’s own web server.</p>
<p>You may have seen lot of Jekyll generated pages already as it was initially created by <a href="https://github.com">GitHub</a> to power their GitHub pages.</p>
<h3 id="why-jekyll">Why Jekyll</h3>
<ul>
<li>Full control of HTML. No crap included.</li>
<li>No online real time editing (a plus for me).</li>
<li>Static HTML, so fast, and secure.</li>
<li>Markdown for posts.</li>
<li>Self hosted (not always a good thing, but works better for me).</li>
<li>Easy and extensive choice of themes.</li>
</ul>
<h3 id="creating-a-jekyll-blog">Creating a Jekyll blog</h3>
<h4 id="develop">Develop</h4>
<p>Jekyll are <a href="https://jekyllrb.com/docs/">installed</a> as a <a href="https://rubygems.org/gems/jekyll/">Ruby Gem</a>.
But you can create it and its pages &amp; posts all inside a <a href="https://hub.docker.com/r/jekyll/jekyll/">Jekyll Docker container</a>.</p>
<h4 id="theme">Theme</h4>
<p>There is a lot of readily available <a href="https://jekyllrb.com/docs/themes/">themes for Jekyll</a>:</p>
<ul>
<li><a href="http://jekyllthemes.org">jekyllthemes.org</a></li>
<li><a href="https://jekyll-themes.com">jekyll-themes.com</a></li>
<li><a href="https://jekyllthemes.io">jekyllthemes.io</a></li>
<li><a href="https://github.com/jekyll/jekyll/wiki/Themes">github.com/jekyll/jekyll/wiki/Themes</a></li>
<li><a href="https://talk.jekyllrb.com/t/jekyll-theme-showcase-share-your-jekyll-themes/">talk.jekyllrb.com/t/jekyll-theme-showcase-share-your-jekyll-themes/</a></li>
<li><a href="https://github.com/planetjekyll/awesome-jekyll-themes">github.com/planetjekyll/awesome-jekyll-themes</a></li>
</ul>
<p>And more if you search for “Jekyll theme”.
Most are free and some you need to pay $25-$49 for.</p>
<p>I would suggest considering a <a href="https://github.com/planetjekyll/awesome-jekyll-themes">Gem based theme</a> for simplicity.</p>
<p>In the end I chose to modify the <a href="https://github.com/artemsheludko/galada">Galada theme by Artem Sheludko</a>.</p>
<h4 id="migrate-posts">Migrate posts</h4>
<p>Thankfully Jekyll includes a lot of <a href="https://import.jekyllrb.com/docs/home/">import tools</a> for migrating from various blog services.
The <a href="https://import.jekyllrb.com/docs/blogger/">Blogger import plugin</a> worked perfectly for me.</p>
<h4 id="building--hosting">Building &amp; Hosting</h4>
<p>You can host your Jekyll site <a href="https://help.github.com/en/articles/using-jekyll-as-a-static-site-generator-with-github-pages">directly with GitHub pages</a>, with <a href="https://jekyllrb.com/docs/deployment/manual/">AWS’ S3</a> or <a href="https://jekyllrb.com/docs/deployment/third-party/">others</a>.</p>
<p>But I prefer a bit more control so I have hosted mine inside my own <a href="https://kubernetes.io">Kubernetes</a> cluster.</p>
<p>I also generate the site and build a Docker image with <a href="https://circleci.com/">CircleCI</a>.</p>
<h3 id="step-by-step-howto">Step by step howto</h3>
<p>For a complete A-Z howto guide on how I create, import, theme, customize, write posts, build and host my now Jekyll based blog, please read <a href="http://flurdy.com/docs/jekyll/">flurdy.com/docs/jekyll/</a></p>flurdyIn my previous post I explained why I decided to migrate my blog away from Blogger. And that I decided to use Jekyll to generate my blog from now on.Migrating blog away from Blogger2019-02-18T18:11:00+00:002019-02-18T18:11:00+00:00https://blog.flurdy.com/2019/02/migrating-blog-away-from-blogger<p>I have finally migrated <a href="http://blog.flurdy.com">my blog</a> away from <a href="http://blogger.com">Blogger</a>. It has been long time comming but the outcome is good.</p>
<p>Blogger have hosted my blog since day 1 untill now (2019).
First at <a href="http://flurdy.blogspot.com">flurdy.blogspot.com</a> then for most of the time at <a href="http://blog.flurdy.com">blog.flurdy.com</a>.
And it has for most part been a great provider over the years.</p>
<h3 id="annoyances">Annoyances</h3>
<p>But there has been a few things that has annoyed me with Blogger:</p>
<ul>
<li>Crap template</li>
<li>Additional garbage</li>
<li>Comment spam</li>
<li>WYSIWYG editing</li>
</ul>
<h4 id="crap-templates">Crap Templates</h4>
<p>The included templates were ok but have not aged gracefully. The content column is very narrow making most of the blog posts harder to read.</p>
<h4 id="additional-garbage">Additional garbage</h4>
<p>The blog pages are filled with lots of scripts and trackers that I do not need.</p>
<h4 id="comment-spam">Comment spam</h4>
<p>There have been over the years some really usefull comments. And I have added comments to follow up some of the posts.
But the last few years a good comment is rare. And 99% is spam.</p>
<h4 id="wysiwyg-editing">WYSIWYG editing</h4>
<p>The default editor is WYSIWYG, and is quite powerful. But I just want raw HTML and in control of the content.
The HTML output Blogger creates is complete trash.</p>
<p>I did for a while draft the blog posts in Google Docs and copy pasted the final content across. But that was messy.</p>
<h3 id="risk">Risk</h3>
<h4 id="killed-by-google">Killed by Google</h4>
<p>The major reason for migrating away from Blogger is the risk posed by Google hosting it.</p>
<p>Google is in general a good company. The “Don’t be evil” mantra may not be quite true anymore but I do believe the company and especially its staff have mostly good intentions.</p>
<p>But they are a heavily automated company, all the interactions you will have with them will be in an automated away. Or as an automated response to something else.</p>
<p>This means on a whim you can have your Blogger account suspended or deleted without much chance of stopping it or even finding out why.
Or worse you entire Google account. Before you know it your blog, photos, email, documents, contacts etc could be gone.</p>
<p>I, as many, did act like <a href="https://en.wikipedia.org/wiki/First_they_came_...">Niemöller’s poem</a> (“First they came for…”) thinking that would not happen to me
then I had an <a href="https://adwords.google.com">Adwords</a> account of mine suspended with no method of finding out why nor any method to restore it.</p>
<p>Which encouraged (spooked) me to continue my process of <a href="https://twitter.com/flurdy/status/1057596122716426240">de-googling myself</a> and I have now moved my blog away from Blogger (and Google).</p>
<h3 id="blog-alternatives">Blog alternatives</h3>
<p>So where is my blog now? There are a many many blog hosting alternatives. Including:</p>
<ul>
<li>Wordpress</li>
<li>Medium</li>
<li>Jekyll</li>
</ul>
<h4 id="wordpress">Wordpress</h4>
<p><a href="http://wordpress.com">Wordpress hosted</a> or <a href="http://wordpress.org">self hosted</a> probably is the most popular blog destination in the world. But Wordpress and PHP is so full of security holes I would not consider it.
And I did not need any online real-time editing tools.</p>
<h4 id="medium">Medium</h4>
<p>Popular amongst friends and peers is <a href="https://medium.com">Medium</a>. But I did not want another hosted solution, and not under another company’s domain.</p>
<h4 id="jekyll">Jekyll</h4>
<p>A static site generated and run with <a href="https://jekyllrb.com">Jekyll</a> ticked all the boxes for me. In my next blog I can detail quickly how I migrated from Blogger and set up my blog with Jekyll.</p>flurdyI have finally migrated my blog away from Blogger. It has been long time comming but the outcome is good.Rusting, a quick dabble with the Rust language2017-04-15T00:12:00+00:002017-04-15T00:12:00+00:00https://blog.flurdy.com/2017/04/rusting-quick-dabble-with-rust-language<span style="font-family: &quot;arial&quot; , &quot;helvetica&quot; , sans-serif;">I have spent a few spare moments in the last week looking at <a href="https://en.wikipedia.org/wiki/Rust_(programming_language)">Rust</a>, a relative new language.<br /><br />With the kids on Easter break and naturally requiring frequent attention, and a few brief actual paid client work, I have not had as long uninterrupted time <span style="font-family: &quot;arial&quot; , &quot;helvetica&quot; , sans-serif;">focused</span> on Rust as I would have liked. But I have managed to knock together some basic code.</span><br /><br /><br /><h4><span style="font-family: &quot;arial&quot; , &quot;helvetica&quot; , sans-serif;">Rustic Pizza</span></h4><br /><span style="font-family: &quot;arial&quot; , &quot;helvetica&quot; , sans-serif;">I created <a href="http://github.com/flurdy/rustic-pizza">github.com/flurdy/rustic-pizza</a> as my playground with rust and various web frameworks. It is very basic code and I expect I will be quite embarrassed by it in just a few months but it is a start. Rustic pizza <span style="font-family: &quot;arial&quot; , &quot;helvetica&quot; , sans-serif;">will eventually contain</span> several very basic web applications each in a different Rust web frameworks, all for ordering pizza. The pizzeria is a concept that I have created many times over in Java and Scala as an example for piece of framework or similar, some of which I have documented on my <a href="http://flurdy.com/">flurdy.com</a> website.</span><br /><br /><br /><h4><span style="font-family: &quot;arial&quot; , &quot;helvetica&quot; , sans-serif;">Experience so far</span></h4><br /><span style="font-family: &quot;arial&quot; , &quot;helvetica&quot; , sans-serif;">So far I have found Rust interesting.&nbsp;</span><br /><br /><span style="font-family: &quot;arial&quot; , &quot;helvetica&quot; , sans-serif;">It perhaps use a bit too much of lazy abbreviated names for its keywords, primitives and core methods than I feel is reasonable, but that is me being pedantic. The ownership transfers, lifetimes and everything by reference is a bit of headfuck, but I think I got the hang of it. Rust does also have some of the monadic traits I am comfortable with from the Scala world, though its <span style="font-family: &quot;arial&quot; , &quot;helvetica&quot; , sans-serif;">F</span>utures seems to be somewhat in its infancy at the moment.</span><br /><br /><br /><h4><span style="font-family: &quot;arial&quot; , &quot;helvetica&quot; , sans-serif;">Install Rust</span></h4><br /><span style="font-family: &quot;arial&quot; , &quot;helvetica&quot; , sans-serif;">Rust can be installed <span style="font-family: &quot;arial&quot; , &quot;helvetica&quot; , sans-serif;">in</span> numerous ways, including via Brew for both Rust and <a href="http://doc.crates.io/">Cargo</a>, its build tool. But I recommend using <a href="https://rustup.rs/">Rustup</a>, <a href="https://rustup.rs/">rustup.rs</a>. Rustup lets you toggle between release and nightly version of Rust, and some frameworks require nightly builds.</span><br /><span style="font-family: &quot;arial&quot; , &quot;helvetica&quot; , sans-serif;"><br /></span><br /><h4><span style="font-family: &quot;arial&quot; , &quot;helvetica&quot; , sans-serif;">Learning Rust</span></h4><br /><span style="font-family: &quot;arial&quot; , &quot;helvetica&quot; , sans-serif;">The main <a href="https://www.rust-lang.org/">Rust website</a>, <a href="https://www.rust-lang.org/">rust-lang.org</a>, is a good place to start to learn about Rust. Especially the "<a href="https://doc.rust-lang.org/book/README.html">Rust book</a>", <a href="https://doc.rust-lang.org/book/README.html">https://doc.rust-lang.org/book/README.html</a>, is a great source to learn about basic Rust concepts. Further reading at <a href="http://rustbyexample.com/index.html">rustbyexample.com/index.html</a> and <a href="https://aturon.github.io/">aturon.github.io</a> was very useful. As well as various blogs on Rust such as <a href="https://hoverbear.org/2017/03/03/setting-up-a-rust-devenv/">hoverbear.org</a> and <a href="http://hermanradtke.com/tags/rustlang.html">hermanradtke.com</a>.<br /><br />Once you start coding I also recommend the standard library documentation, <a href="https://doc.rust-lang.org/std/">doc.rust-lang.org/std/,</a> to find out what methods are available, e.g. does option have map, and what is getOrElse called in rust (unwrap) etc.</span><br /><span style="font-family: &quot;arial&quot; , &quot;helvetica&quot; , sans-serif;"><br /></span><br /><h4><span style="font-family: &quot;arial&quot; , &quot;helvetica&quot; , sans-serif;">Web frameworks</span></h4><br /><span style="font-family: &quot;arial&quot; , &quot;helvetica&quot; , sans-serif;">As I most of the time create web services or full webapps an important part of my interest is which web frameworks are available. Fortunately the Rust community also recognise the importance of this, so <a href="http://www.arewewebyet.org/">www.arewewebyet.org</a> and <a href="https://github.com/flosse/rust-web-framework-comparison">github.com/flosse/rust-web-framework-comparison</a> are great information on which frameworks and libraries are available with Rust.<br /><br />This lead me to take a look at the newest kid on the block <a href="https://rocket.rs/">Rocket</a>, <a href="https://rocket.rs/">rocket.rs</a>. So far Rocket have worked very well for me. <br /><br />For my Rustic Pizza I plan to also take a look at <a href="http://ironframework.io/">Iron</a>, <a href="http://ironframework.io/">http://ironframework.io</a>, as it is the most popular Rust web framework on github. Though it has not been updated as much lately compared to Rocket.<br /><br />Hopefully if time allows I may get to look more in depth into <a href="http://nickel.rs/">Nickel</a>, <a href="https://github.com/conduit-rust/conduit">Conduit</a> and <a href="https://github.com/Ogeon/rustful">Rustful</a> as well.</span><br /><span style="font-family: &quot;arial&quot; , &quot;helvetica&quot; , sans-serif;"><br /></span><br /><h4><span style="font-family: &quot;arial&quot; , &quot;helvetica&quot; , sans-serif;">Keep rusting?</span></h4><br /><span style="font-family: &quot;arial&quot; , &quot;helvetica&quot; , sans-serif;">Whether I will keep using Rust time will tell. Core Rust concepts such as ownership, references, memory management etc are not aspects I care to manually control and think about too much as I hope a compiler and garbage collector optimises and ha<span style="font-family: &quot;arial&quot; , &quot;helvetica&quot; , sans-serif;">ndles</span> those for me. But I will keep at it so maybe Rust will accompany if not replace Scala as the main hammer in my toolbox some day.</span><br /><br /><span style="font-family: &quot;arial&quot; , &quot;helvetica&quot; , sans-serif;"><br /></span>flurdyI have spent a few spare moments in the last week looking at Rust, a relative new language.With the kids on Easter break and naturally requiring frequent attention, and a few brief actual paid client work, I have not had as long uninterrupted time focused on Rust as I would have liked. But I have managed to knock together some basic code.Rustic PizzaI created github.com/flurdy/rustic-pizza as my playground with rust and various web frameworks. It is very basic code and I expect I will be quite embarrassed by it in just a few months but it is a start. Rustic pizza will eventually contain several very basic web applications each in a different Rust web frameworks, all for ordering pizza. The pizzeria is a concept that I have created many times over in Java and Scala as an example for piece of framework or similar, some of which I have documented on my flurdy.com website.Experience so farSo far I have found Rust interesting.&nbsp;It perhaps use a bit too much of lazy abbreviated names for its keywords, primitives and core methods than I feel is reasonable, but that is me being pedantic. The ownership transfers, lifetimes and everything by reference is a bit of headfuck, but I think I got the hang of it. Rust does also have some of the monadic traits I am comfortable with from the Scala world, though its Futures seems to be somewhat in its infancy at the moment.Install RustRust can be installed in numerous ways, including via Brew for both Rust and Cargo, its build tool. But I recommend using Rustup, rustup.rs. Rustup lets you toggle between release and nightly version of Rust, and some frameworks require nightly builds.Learning RustThe main Rust website, rust-lang.org, is a good place to start to learn about Rust. Especially the "Rust book", https://doc.rust-lang.org/book/README.html, is a great source to learn about basic Rust concepts. Further reading at rustbyexample.com/index.html and aturon.github.io was very useful. As well as various blogs on Rust such as hoverbear.org and hermanradtke.com.Once you start coding I also recommend the standard library documentation, doc.rust-lang.org/std/, to find out what methods are available, e.g. does option have map, and what is getOrElse called in rust (unwrap) etc.Web frameworksAs I most of the time create web services or full webapps an important part of my interest is which web frameworks are available. Fortunately the Rust community also recognise the importance of this, so www.arewewebyet.org and github.com/flosse/rust-web-framework-comparison are great information on which frameworks and libraries are available with Rust.This lead me to take a look at the newest kid on the block Rocket, rocket.rs. So far Rocket have worked very well for me. For my Rustic Pizza I plan to also take a look at Iron, http://ironframework.io, as it is the most popular Rust web framework on github. Though it has not been updated as much lately compared to Rocket.Hopefully if time allows I may get to look more in depth into Nickel, Conduit and Rustful as well.Keep rusting?Whether I will keep using Rust time will tell. Core Rust concepts such as ownership, references, memory management etc are not aspects I care to manually control and think about too much as I hope a compiler and garbage collector optimises and handles those for me. But I will keep at it so maybe Rust will accompany if not replace Scala as the main hammer in my toolbox some day.Pair first, pair always, never occasionally2017-03-10T01:42:00+00:002017-03-10T01:42:00+00:00https://blog.flurdy.com/2017/03/pair-first-pair-always-never-occasionaly<h3><span style="font-family: &quot;trebuchet ms&quot; , sans-serif;">Pair first </span></h3><br /><span style="font-family: &quot;trebuchet ms&quot; , sans-serif;">Think pair programming first by making it default for all tasks, not the optional occasional pairing which is how most places fake pairing.</span><br /><span style="font-family: &quot;trebuchet ms&quot; , sans-serif;"></span><br /><span style="font-family: &quot;trebuchet ms&quot; , sans-serif;"><br /></span><br /><h3><span style="font-family: &quot;trebuchet ms&quot; , sans-serif;">Why pair</span></h3><span style="font-family: &quot;trebuchet ms&quot; , sans-serif;"><br />I have already ranted why pairing is so beneficial in <a href="http://blog.flurdy.com/2015/03/pair-up-now.html">"Pair up now"</a>. I have since worked in pair-always teams for another two years and really can’t fathom the waste of not pairing in any future projects.</span><br /><span style="font-family: &quot;trebuchet ms&quot; , sans-serif;"></span><br /><span style="font-family: &quot;trebuchet ms&quot; , sans-serif;"></span><br /><span style="font-family: &quot;trebuchet ms&quot; , sans-serif;"><br /></span><br /><h3><span style="font-family: &quot;trebuchet ms&quot; , sans-serif;">Don’t do optional pairing</span><span style="font-family: &quot;trebuchet ms&quot; , sans-serif;"> </span></h3><span style="font-family: &quot;trebuchet ms&quot; , sans-serif;"><br />Many places, and I used to work at a few, do optional pairing. They say they pair occasionally as and when the team members think they want to. </span><br /><span style="font-family: &quot;trebuchet ms&quot; , sans-serif;"></span><br /><span style="font-family: &quot;trebuchet ms&quot; , sans-serif;"></span><span style="font-family: &quot;trebuchet ms&quot; , sans-serif;">I call this fake pairing. As it does not happen very often, and is more like as a second opinion or help when someone gets stuck on a task for a short time. That is not what pairing is. Please read the blog post mentioned above what pairing actually means. (code quality, knowledge share, low bus factor, best practices, egalitarian technology, feature speed)</span><br /><span style="font-family: &quot;trebuchet ms&quot; , sans-serif;"><br />Optional pairing lets people find excuses to not pair even when they think the tasks may be more suitable as a pairing tasks. Or wait until people are available which is wasteful as well as context switch cost for the other temporary pair member.</span><br /><span style="font-family: &quot;trebuchet ms&quot; , sans-serif;"><br />Optional pairing is better than no pairing, but only slightly.</span><br /><span style="font-family: &quot;trebuchet ms&quot; , sans-serif;"><br /></span><span style="font-family: &quot;trebuchet ms&quot; , sans-serif;"><br /></span><br /><h3><span style="font-family: &quot;trebuchet ms&quot; , sans-serif;">Default to pair</span></h3><span style="font-family: &quot;trebuchet ms&quot; , sans-serif;"><br /></span><span style="font-family: &quot;trebuchet ms&quot; , sans-serif;">By making it default you avoid discussion if one should pair or not. It is less ambiguous and the team just gets on with the tasks straight away. You realise most tasks can be paired on.</span><br /><span style="font-family: &quot;trebuchet ms&quot; , sans-serif;"><br />You also then start to see the big benefits of everyone pairing over time. You will start to notice higher quality code, that less bugs creep through and the code start to be quite lean as unnecessary code does not even get written. And the flow of tasks is steady as there is less bottlenecks of people with sole knowledge of some part of the system as the knowledge is spread across the team</span><br /><span style="font-family: &quot;trebuchet ms&quot; , sans-serif;"><br />You will have a team that knows each other better, that really work as a team. A team that has shared their own ideas and niche knowledge of technology. The code base now also looks more homogeneous and evolved as the team has improved their abilities unilaterally.</span><br /><span style="font-family: &quot;trebuchet ms&quot; , sans-serif;"><br /></span><span style="font-family: &quot;trebuchet ms&quot; , sans-serif;"></span><br /><span style="font-family: &quot;trebuchet ms&quot; , sans-serif;"><br /></span><br /><h3><span style="font-family: &quot;trebuchet ms&quot; , sans-serif;">Non pair tasks</span></h3><span style="font-family: &quot;trebuchet ms&quot; , sans-serif;"><br />Sure as mentioned in my previous post there are still tasks that does not need to paired on. But there are fewer of these than you think. Mostly research tasks etc can be done alone. Or a pair may not sit together whilst ‘googling’ separately for a bit. </span><br /><span style="font-family: &quot;trebuchet ms&quot; , sans-serif;"><br />If someone is working solo on a task it is important that these tasks are minimised and time boxed as they often become time sinks and over complicated solutions thought of.</span><br /><span style="font-family: &quot;trebuchet ms&quot; , sans-serif;"></span><br /><span style="font-family: &quot;trebuchet ms&quot; , sans-serif;"><br /></span><span style="font-family: &quot;trebuchet ms&quot; , sans-serif;"><br /></span><br /><h3><span style="font-family: &quot;trebuchet ms&quot; , sans-serif;">Odd number of team members</span></h3><span style="font-family: &quot;trebuchet ms&quot; , sans-serif;"><br /></span><span style="font-family: &quot;trebuchet ms&quot; , sans-serif;">Often though through holiday, sickness, meetings, team rotation etc there is an odd number of members in the team making pairing everyone mathematically impossible.</span><br /><span style="font-family: &quot;trebuchet ms&quot; , sans-serif;"><br />You could triple up on one task. It can be done, though often end up with too many cooks in the kitchen. There may be suitably encapsulated sub tasks that the third triple member can work on his/her own and sync with the others frequently instead.</span><br /><span style="font-family: &quot;trebuchet ms&quot; , sans-serif;"><br />You could let the odd team member pick up a normal task as an individual. This can also work but I recommend highly against it. Many times I have seen this just result in the problems pairing was meant to solve. They get too entrenched in the task and it takes longer than planned. Or get defensive about it. Or it gets over-engineered. Or they take shortcuts or bad technology choices that would not have happened if paired on.</span><br /><span style="font-family: &quot;trebuchet ms&quot; , sans-serif;"><br />If there are some obvious non pair tasks to pick up then it might be a suitable filler until pair rotation happens again or a new member becomes available. Tasks such as perhaps some rare support or monitoring, or evaluate some low priority PRs. </span><br /><span style="font-family: &quot;trebuchet ms&quot; , sans-serif;"><br />Or they can work on some fun but non priority technical debt. Such as automating wall displays, or support scripts or tools to simplify/automate a process. It provides a nice break from the other normal tasks, and also hopefully helps the team in the future and reduces <a href="http://blog.flurdy.com/2014/02/paper-cuts-and-broken-windows.html">paper cuts</a>. </span><br /><span style="font-family: &quot;trebuchet ms&quot; , sans-serif;"></span><br /><span style="font-family: &quot;trebuchet ms&quot; , sans-serif;"><br /></span><span style="font-family: &quot;trebuchet ms&quot; , sans-serif;"><br /></span><br /><h3><span style="font-family: &quot;trebuchet ms&quot; , sans-serif;">Don’t chicken out</span></h3><span style="font-family: &quot;trebuchet ms&quot; , sans-serif;"><br /></span><span style="font-family: &quot;trebuchet ms&quot; , sans-serif;">So do not chicken out by agreeing only to pair when the task's problem is suitable. Instead always plan to pair unless it is a rare hands off research task or similar.</span><br /><br /><br />flurdyPair first Think pair programming first by making it default for all tasks, not the optional occasional pairing which is how most places fake pairing.Why pairI have already ranted why pairing is so beneficial in "Pair up now". I have since worked in pair-always teams for another two years and really can’t fathom the waste of not pairing in any future projects.Don’t do optional pairing Many places, and I used to work at a few, do optional pairing. They say they pair occasionally as and when the team members think they want to. I call this fake pairing. As it does not happen very often, and is more like as a second opinion or help when someone gets stuck on a task for a short time. That is not what pairing is. Please read the blog post mentioned above what pairing actually means. (code quality, knowledge share, low bus factor, best practices, egalitarian technology, feature speed)Optional pairing lets people find excuses to not pair even when they think the tasks may be more suitable as a pairing tasks. Or wait until people are available which is wasteful as well as context switch cost for the other temporary pair member.Optional pairing is better than no pairing, but only slightly.Default to pairBy making it default you avoid discussion if one should pair or not. It is less ambiguous and the team just gets on with the tasks straight away. You realise most tasks can be paired on.You also then start to see the big benefits of everyone pairing over time. You will start to notice higher quality code, that less bugs creep through and the code start to be quite lean as unnecessary code does not even get written. And the flow of tasks is steady as there is less bottlenecks of people with sole knowledge of some part of the system as the knowledge is spread across the teamYou will have a team that knows each other better, that really work as a team. A team that has shared their own ideas and niche knowledge of technology. The code base now also looks more homogeneous and evolved as the team has improved their abilities unilaterally.Non pair tasksSure as mentioned in my previous post there are still tasks that does not need to paired on. But there are fewer of these than you think. Mostly research tasks etc can be done alone. Or a pair may not sit together whilst ‘googling’ separately for a bit. If someone is working solo on a task it is important that these tasks are minimised and time boxed as they often become time sinks and over complicated solutions thought of.Odd number of team membersOften though through holiday, sickness, meetings, team rotation etc there is an odd number of members in the team making pairing everyone mathematically impossible.You could triple up on one task. It can be done, though often end up with too many cooks in the kitchen. There may be suitably encapsulated sub tasks that the third triple member can work on his/her own and sync with the others frequently instead.You could let the odd team member pick up a normal task as an individual. This can also work but I recommend highly against it. Many times I have seen this just result in the problems pairing was meant to solve. They get too entrenched in the task and it takes longer than planned. Or get defensive about it. Or it gets over-engineered. Or they take shortcuts or bad technology choices that would not have happened if paired on.If there are some obvious non pair tasks to pick up then it might be a suitable filler until pair rotation happens again or a new member becomes available. Tasks such as perhaps some rare support or monitoring, or evaluate some low priority PRs. Or they can work on some fun but non priority technical debt. Such as automating wall displays, or support scripts or tools to simplify/automate a process. It provides a nice break from the other normal tasks, and also hopefully helps the team in the future and reduces paper cuts. Don’t chicken outSo do not chicken out by agreeing only to pair when the task's problem is suitable. Instead always plan to pair unless it is a rare hands off research task or similar.ROC theorem: Readable, Optimised and Correct code. Pick two.2016-11-22T14:35:00+00:002016-11-22T14:35:00+00:00https://blog.flurdy.com/2016/11/roc-theorem-readable-optimised-correct-code<h4>ROC theorem</h4><br />With database you have the well known <a href="https://en.wikipedia.org/wiki/CAP_theorem">CAP theorem</a>. Consistency, Availability and Partition Tolerance. You can only have two. Databases have to make compromises between these pillars. You can not fully have all three.<br /><br />With code you also have to decide on compromises between readable code, optimised code and correct code (ROC). And you can not have all three.<br /><br />This often creates arguments between people on soap boxes from the various camps.<br /><br /><br /><h3>Correct code</h3><br />Correct code, clever, terse, generic code that avoids handling a lot of edge cases. Often functional code that can be very elegant with little to no theoretic side effects. And easily composed as part of other code.<br /><br />Correct code can be readable and fast, but also sometimes horrible to understand and very costly to train, write and maintain.<br /><br /><br /><h3>Optimised code</h3><br />Optimised code, fast and scalable. No unnecessary cruft and takes short cuts to achieve the end results so performant from day one.<br /><br />Scalable code, code you optimise to support horizontal scalable solutions, with little state and restartable.<br /><br />May discourage typed system e.g. a message based Actor system, multiple layers of caching, or overuse of parallelised futures to avoid bottlenecks.<br /><br />Optimised code can be "correct" code but often full of unclear and undocumented short cuts and frustratingly slow/buggy to develop.<br /><br /><br /><h3>Readable code</h3><br />Readable code, simple to read and quick to understand, by people of different levels of skill. Easy to spot bugs and is maintainable by anyone. It is pragmatic in its approach and quick to develop. Can be terse if it is the most readable but often more verbose.<br /><br />Readable can be "correct" as flow is easier to understand, but often not particularly performant and can be at more at risk of bugs due to more exposed code.<br /><br /><br /><h3>Not mutually exclusive</h3><br />You can have all 3 pillars for some smaller sets of code. But not for whole code bases and at a cost for how much.<br /><br />This is more about the priority and focus of the code you write.<br /><ul><li>Will others work on the code base, today, next week, next year? Then readable is important.</li><li>Is multiple people working on the same part of the code base? From different teams? With varied experience, or even just different locations? Then readable is important.</li><li>Is the solution used by millions? Does big O make any difference? Then consider optimised code. Note: very, very few companies/products actually need this.</li><li>Is a bottleneck been proven in production? Then optimised code is valid. But not necessarily across the code base.</li><li>Is the product business critical? With heavy integration dependants? Then correct code may be a priority.</li><li>Is the team highly skilled? Not that large, and low churn? Then correct code is an option.</li><li>Do you pair program 100%, from day 1 of onboarding? Then correct code is an option.</li></ul>With unlimited time to implement and continuously heavy training, and therefore a lot money, you may achieve higher levels of 2 of them or even all 3. But that is not realistic. Pick your priorities. These are not mutually exclusive but they are at a cost of each other.<br /><br /><br /><h3>All the ROCs</h3><br />You may detect my preferences. I prefer very simple and readable code, that is functional, and scalable. In that order.<br /><br />I like that anyone can pick up and work on a task for most parts of a code base. I subscribe to the idea of frequent pair rotation across tasks and systems to make sure multiple people is aware of and had an input into any part of an architecture. That leads towards readable code so the overhead of swapping is low.<br /><br />That a new member of our team or from another team in 6 months time can easily contribute to "our" code base for a small pull request without learning "our take" on <a href="https://en.wikipedia.org/wiki/Category_theory">category theory</a> is valuable.<br /><br />I prefer functional programming, with proper type checking, using functors and monads for composition. I like terse code that I can trust, but it must still be readable and maintainable by others than the original author(s).<br /><br />So some overuse of higher kinded types, free monads, etc adds too much cruft for me, and risky recruitment demands. (At the moment, I am prone to evolve and may have completely changed my mind by the time you read this...)<br /><br />Horizontally scalable, concurrent code is in the back of my mind of most of solutions. No state, using futures, REST principles etc are core to all my code.<br /><br />But I detest premature optimisation. Only occasionally in my career have I had to modify any code to support some optimised flow. I do not work for Facebook/Twitter/Google (yet) but I have worked for financial, telcos, and games companies with enormous traffic, and still this was rarely a problem at code level.<br /><br />I often spot potential optimisations and consciously say no, not yet, if it is not also the most readable and correct alternative. I even avoid parallelisation of futures if there is not yet any obvious need especially if it makes the code less readable.<br /><br /><br /><h4>Readable, Optimised and Correct code. ROC. Pick two. Or just rank them.</h4><div><br /></div><div><br /></div><div><br /></div>flurdyROC theoremWith database you have the well known CAP theorem. Consistency, Availability and Partition Tolerance. You can only have two. Databases have to make compromises between these pillars. You can not fully have all three.With code you also have to decide on compromises between readable code, optimised code and correct code (ROC). And you can not have all three.This often creates arguments between people on soap boxes from the various camps.Correct codeCorrect code, clever, terse, generic code that avoids handling a lot of edge cases. Often functional code that can be very elegant with little to no theoretic side effects. And easily composed as part of other code.Correct code can be readable and fast, but also sometimes horrible to understand and very costly to train, write and maintain.Optimised codeOptimised code, fast and scalable. No unnecessary cruft and takes short cuts to achieve the end results so performant from day one.Scalable code, code you optimise to support horizontal scalable solutions, with little state and restartable.May discourage typed system e.g. a message based Actor system, multiple layers of caching, or overuse of parallelised futures to avoid bottlenecks.Optimised code can be "correct" code but often full of unclear and undocumented short cuts and frustratingly slow/buggy to develop.Readable codeReadable code, simple to read and quick to understand, by people of different levels of skill. Easy to spot bugs and is maintainable by anyone. It is pragmatic in its approach and quick to develop. Can be terse if it is the most readable but often more verbose.Readable can be "correct" as flow is easier to understand, but often not particularly performant and can be at more at risk of bugs due to more exposed code.Not mutually exclusiveYou can have all 3 pillars for some smaller sets of code. But not for whole code bases and at a cost for how much.This is more about the priority and focus of the code you write.Will others work on the code base, today, next week, next year? Then readable is important.Is multiple people working on the same part of the code base? From different teams? With varied experience, or even just different locations? Then readable is important.Is the solution used by millions? Does big O make any difference? Then consider optimised code. Note: very, very few companies/products actually need this.Is a bottleneck been proven in production? Then optimised code is valid. But not necessarily across the code base.Is the product business critical? With heavy integration dependants? Then correct code may be a priority.Is the team highly skilled? Not that large, and low churn? Then correct code is an option.Do you pair program 100%, from day 1 of onboarding? Then correct code is an option.With unlimited time to implement and continuously heavy training, and therefore a lot money, you may achieve higher levels of 2 of them or even all 3. But that is not realistic. Pick your priorities. These are not mutually exclusive but they are at a cost of each other.All the ROCsYou may detect my preferences. I prefer very simple and readable code, that is functional, and scalable. In that order.I like that anyone can pick up and work on a task for most parts of a code base. I subscribe to the idea of frequent pair rotation across tasks and systems to make sure multiple people is aware of and had an input into any part of an architecture. That leads towards readable code so the overhead of swapping is low.That a new member of our team or from another team in 6 months time can easily contribute to "our" code base for a small pull request without learning "our take" on category theory is valuable.I prefer functional programming, with proper type checking, using functors and monads for composition. I like terse code that I can trust, but it must still be readable and maintainable by others than the original author(s).So some overuse of higher kinded types, free monads, etc adds too much cruft for me, and risky recruitment demands. (At the moment, I am prone to evolve and may have completely changed my mind by the time you read this...)Horizontally scalable, concurrent code is in the back of my mind of most of solutions. No state, using futures, REST principles etc are core to all my code.But I detest premature optimisation. Only occasionally in my career have I had to modify any code to support some optimised flow. I do not work for Facebook/Twitter/Google (yet) but I have worked for financial, telcos, and games companies with enormous traffic, and still this was rarely a problem at code level.I often spot potential optimisations and consciously say no, not yet, if it is not also the most readable and correct alternative. I even avoid parallelisation of futures if there is not yet any obvious need especially if it makes the code less readable.Readable, Optimised and Correct code. ROC. Pick two. Or just rank them.Contracting 1012015-10-09T11:33:00+00:002015-10-09T11:33:00+00:00https://blog.flurdy.com/2015/10/contracting-101<span style="font-family: Arial, Helvetica, sans-serif;">Seems a large number of people I meet are interested in becoming a contractor/consultant/freelancer. So I thought I better write a up what I did and recommend. Note this is very UK / London centric.</span><br /><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span><br /><h3><span style="font-family: Arial, Helvetica, sans-serif;">Information&nbsp;</span></h3><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span><span style="font-family: Arial, Helvetica, sans-serif;">For general information, tools, conversations and advice on contracting in the UK <a href="http://contractoruk.com/">contractoruk.com</a> and&nbsp;<a href="http://www.contractorcalculator.co.uk/">contractorcalculator.co.uk</a> are very good sites. And a very dodgy contractor calculator... <a href="http://grid.flurdy.com/contractCalc">grid.flurdy.com/contractCalc</a></span><br /><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span><br /><h3><span style="font-family: Arial, Helvetica, sans-serif;">Forums</span></h3><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span><span style="font-family: Arial, Helvetica, sans-serif;">The forums at <a href="http://forums.contractoruk.com/">forums.contractoruk.com</a> have been a great help to me. But prepare to be condescended and shot down if asking noob questions.&nbsp;</span><br /><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span><br /><h3><span style="font-family: Arial, Helvetica, sans-serif;">Association</span></h3><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span><span style="font-family: Arial, Helvetica, sans-serif;"><a href="http://www.ipse.co.uk/">IPSE</a>, formerly known as PCG, the major contractor and freelancer association in the UK. <a href="https://www.ipse.co.uk/">ipse.co.uk</a>&nbsp;</span><br /><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span><span style="font-family: Arial, Helvetica, sans-serif;">They will represent you if you have disputes with the <a href="https://en.wikipedia.org/wiki/HM_Revenue_and_Customs">HMRC</a> of which they have a great track record. And they offer a range of services in general that will help you sleep at night. And <a href="https://www.ipse.co.uk/ipse-advantages">discounts with Apple</a> etc. Membership is a no brainer. You can use my referral code of <i>IPSEMGM0921</i> if you want.</span><br /><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span><br /><h3><span style="font-family: Arial, Helvetica, sans-serif;">Insurance</span></h3><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span><span style="font-family: Arial, Helvetica, sans-serif;">You will need indemnity and public liability insurance and optionally others such as IR35 cover. <a href="http://www.qdoscontractor.com/">QDos</a> came recommended in the forums. Don’t under insure yourself but also don’t over insure. <a href="http://www.qdoscontractor.com/">qdoscontractor.com</a></span><br /><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span><br /><h3><span style="font-family: Arial, Helvetica, sans-serif;">Umbrella</span></h3><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span><span style="font-family: Arial, Helvetica, sans-serif;">To soften the move to contracting world I joined an umbrella company initially. Basically the only paperwork you need to worry about then is the contract renewal. I was with <a href="http://www.contractorumbrella.com/">contractorumbrella.com</a> and they were great.&nbsp;</span><br /><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span><span style="font-family: Arial, Helvetica, sans-serif;">But eventually I took the next step to become a limited company as Umbrella taxes do add up.</span><br /><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span><br /><h3><span style="font-family: Arial, Helvetica, sans-serif;">Accountants</span></h3><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span><span style="font-family: Arial, Helvetica, sans-serif;">As a limited company you need an accountant. I joined <a href="https://www.crunch.co.uk/">Crunch</a> as they have web site that automate almost everything on top of friendly advice. <a href="https://www.crunch.co.uk/">crunch.co.uk</a> So far they have been great. Please use referral <i>eraybyfl</i> to receive Amazon vouchers.</span><br /><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span><br /><h3><span style="font-family: Arial, Helvetica, sans-serif;">Finding contracts</span></h3><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span><span style="font-family: Arial, Helvetica, sans-serif;">To find contracts is the major challenge. If you have a great network where you turn down work, then marvelous. Network at meetups and conferences. Verbally sell yourself to former colleagues as they may not be aware you could help them with a problem they have at work. Get business cards from <a href="http://moo.com/">moo.com</a></span><br /><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span><span style="font-family: Arial, Helvetica, sans-serif;">Otherwise global project sites such as <a href="http://elance.com/">Elance</a>/<a href="http://odesk.com/">ODesk</a>/<a href="http://upwork.com/">Upwork</a> can turn up some work, just remember to not bankrupt yourself. I have actually had the best responses when I quoted a lot higher than anyone else.&nbsp;</span><br /><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span><span style="font-family: Arial, Helvetica, sans-serif;">Job sites such as <a href="http://jobserve.com/">jobserve.com</a>, <a href="http://jobsite.co.uk/">jobsite.co.uk</a>, etc is the normal way to find contracts. Be aware a large chunk is simply cv fishing and not real job ads.&nbsp;</span><br /><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span><br /><h3><span style="font-family: Arial, Helvetica, sans-serif;">Contract Recruiters</span></h3><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span><span style="font-family: Arial, Helvetica, sans-serif;">If you can go direct then great, but most of the time you will have to deal with recruiters, and contract recruiters are much worse than normal recruiters, which does say something. Especially in a numbers game location such as London.&nbsp;</span><br /><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span><span style="font-family: Arial, Helvetica, sans-serif;">The major difference is for permie roles the recruiter will be better off if you agree a higher salary, whilst with contracts the recruiter/agency will be better off the lower they can get your rate.&nbsp;</span><br /><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span><span style="font-family: Arial, Helvetica, sans-serif;">And never ever believe them requiring two references. That is only so that they can extend their contact list.&nbsp;</span><br /><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span><br /><h3><span style="font-family: Arial, Helvetica, sans-serif;">Office Space</span></h3><div><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div><span style="font-family: Arial, Helvetica, sans-serif;">If you are not at a client I recommend using shared workspaces. I frequently use the 4 days a month for free IPSE members receive with Club Workspace </span><span style="font-family: Arial, Helvetica, sans-serif;"><a href="http://club.workspacegroup.co.uk/">club.workspacegroup.co.uk</a>. I have also used <a href="http://neardesk.com/">neardesk.com</a> and the more corporate <a href="http://regus.co.uk/">regus.co.uk</a>.&nbsp;</span><br /><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span><span style="font-family: Arial, Helvetica, sans-serif;">Good luck</span><br /><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span><span style="font-family: Arial, Helvetica, sans-serif;">Ivar Abrahamsen</span><br /><span style="font-family: Arial, Helvetica, sans-serif;">Benevolent Dictator / Technical Architect Consultant</span><br /><br /><span style="font-family: Arial, Helvetica, sans-serif;">Eray by Flurdy Ltd&nbsp;</span><br /><span style="font-family: Arial, Helvetica, sans-serif;"><a href="http://eray.uk/">eray.uk</a>&nbsp;|&nbsp;<a href="http://flurdy.com/">flurdy.com</a></span><br /><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>flurdySeems a large number of people I meet are interested in becoming a contractor/consultant/freelancer. So I thought I better write a up what I did and recommend. Note this is very UK / London centric.Information&nbsp;For general information, tools, conversations and advice on contracting in the UK contractoruk.com and&nbsp;contractorcalculator.co.uk are very good sites. And a very dodgy contractor calculator... grid.flurdy.com/contractCalcForumsThe forums at forums.contractoruk.com have been a great help to me. But prepare to be condescended and shot down if asking noob questions.&nbsp;AssociationIPSE, formerly known as PCG, the major contractor and freelancer association in the UK. ipse.co.uk&nbsp;They will represent you if you have disputes with the HMRC of which they have a great track record. And they offer a range of services in general that will help you sleep at night. And discounts with Apple etc. Membership is a no brainer. You can use my referral code of IPSEMGM0921 if you want.InsuranceYou will need indemnity and public liability insurance and optionally others such as IR35 cover. QDos came recommended in the forums. Don’t under insure yourself but also don’t over insure. qdoscontractor.comUmbrellaTo soften the move to contracting world I joined an umbrella company initially. Basically the only paperwork you need to worry about then is the contract renewal. I was with contractorumbrella.com and they were great.&nbsp;But eventually I took the next step to become a limited company as Umbrella taxes do add up.AccountantsAs a limited company you need an accountant. I joined Crunch as they have web site that automate almost everything on top of friendly advice. crunch.co.uk So far they have been great. Please use referral eraybyfl to receive Amazon vouchers.Finding contractsTo find contracts is the major challenge. If you have a great network where you turn down work, then marvelous. Network at meetups and conferences. Verbally sell yourself to former colleagues as they may not be aware you could help them with a problem they have at work. Get business cards from moo.comOtherwise global project sites such as Elance/ODesk/Upwork can turn up some work, just remember to not bankrupt yourself. I have actually had the best responses when I quoted a lot higher than anyone else.&nbsp;Job sites such as jobserve.com, jobsite.co.uk, etc is the normal way to find contracts. Be aware a large chunk is simply cv fishing and not real job ads.&nbsp;Contract RecruitersIf you can go direct then great, but most of the time you will have to deal with recruiters, and contract recruiters are much worse than normal recruiters, which does say something. Especially in a numbers game location such as London.&nbsp;The major difference is for permie roles the recruiter will be better off if you agree a higher salary, whilst with contracts the recruiter/agency will be better off the lower they can get your rate.&nbsp;And never ever believe them requiring two references. That is only so that they can extend their contact list.&nbsp;Office SpaceIf you are not at a client I recommend using shared workspaces. I frequently use the 4 days a month for free IPSE members receive with Club Workspace club.workspacegroup.co.uk. I have also used neardesk.com and the more corporate regus.co.uk.&nbsp;Good luckIvar AbrahamsenBenevolent Dictator / Technical Architect ConsultantEray by Flurdy Ltd&nbsp;eray.uk&nbsp;|&nbsp;flurdy.comPair up now2015-03-19T17:48:00+00:002015-03-19T17:48:00+00:00https://blog.flurdy.com/2015/03/pair-up-now<br />I fully believe we can deliver faster projects, with better code, exposing less risk to the company and in the end be more profitable if team members <a href="https://en.wikipedia.org/wiki/Pair_programming">pair program</a>.<br /><br /><br /><h3>The world was fine before</h3><br />The world and businesses worked for thousands of years, even decades since computers was invented before agile methodologies took over how projects and companies was run. Projects was delivered and companies didn’t go bust.<br /><br />Workable products got shipped before testing was done thoroughly, before unit testing was common and TDD was even heard of.<br /><br class="Apple-interchange-newline" />At the same time many teams worked well, developers wrote good code, meeting deadlines and shipping products before pair programming was a thing.<br /><div><br /></div><div><h4>Sort of..</h4><br />Were we also fine before cars replaced horses, computers replaced pen and paper, modern medicine replaced witch doctors?<br /><br />Before Agile projects was delivered often late, not meeting the updated requirements, and all the other benefits with Agile. But some was delivered on time with features as desired and to budget. Just fewer and a lot slower.<br /><br />And products were shipped with many bugs over and over again, with costly fixes over and over again.<br /><br /><br /><br /><h3>Why not pair?</h3><br /><h4>Double the resource cost</h4><br />Many companies and managers can not see past the issue of using two people on one problem. Basically doubling the resourcing cost per story/task/whatever.<br /><br />And some (not many) are aware of the teachings of the <a href="https://en.wikipedia.org/wiki/The_Mythical_Man-Month">Mythical Man Month</a>&nbsp;that adding more resources to a problem is not a linear reduction in time to finish the problem.<br /><br /><br /><h4>My space - my own thing</h4><br />Many people and developers are also not interested in working with others on a task, especially all the time. They feel their private space violated and interfering with their work habits. I/they/most people do like to think and experiment and solve a problem on their own. And be trusted to do so.<br /><br />Being forced to sit and watch, to talk to another person about every step of solving a problem is a big change in work habits and social skill requirements.<br /><br /><br /><h4>So why pair program?</h4><br />3 reasons: Code Quality, Knowledge Share and Feature Speed.<br /><br /><br /><h3>Code quality</h3><br /><h4>Mini plan</h4><br />If two people sit together to work on a task they are quite likely to discuss the issue and basically perform a mini up-front architecture analysis of the problem. They might even apply TDD approach to solving it. In essence it should deliver a slightly more thought out solution than simply jumping in the deep end and hacking out a solution.<br /><br /><h4>Human rubber duck</h4><br />Explaining the problem and solution to a human <a href="https://en.wikipedia.org/wiki/Rubber_duck_debugging">rubber duck</a> also unveils the root cause and the better solution much quicker.<br /><br /><h4>Less rabbit holes</h4><br />Two people are less likely though not guaranteed to go down a completely wrong rabbit hole in solving the problem. And at least quicker to realise that they are and pull out out sooner.<br /><br /><h4>No short cuts</h4><br />If you sit with someone you are less likely to cut corners and take short cuts in your approach and implementation. This is a very good reason for why pair programming results in better code quality. You are for example less likely to skip writing tests if someone sits with you.<br /><br /><h4>Less mistakes</h4><br />Simple mistakes and syntax errors are quickly spotted and corrected. Human compiler and typo spotter is often what happens but that is not really a bad thing, just don’t be offended by it.<br /><h4><br />Clean readable code</h4><br />By having two people agree on the implementation then the readability and approach to the code should be cleaner and more maintainable as you both have to agree and understand the delivered implementation. This basically negates the need for extensive code review process later on as covered in my "<a href="http://blog.flurdy.com/2013/11/code-review-with-people-you-dont-like.html">Pair with people you like and code reviews with people you don't like</a>"&nbsp;blog post<br /><br /><h4>Ninja code</h4><br />A lone developer often so called ninjas may also try to write smart code. Code that none else can understand nor maintain when that person leaves. A pair would <a href="http://blogs.atlassian.com/2009/06/pair_programming_is_kryptonite/">prevent writing code</a> that is unnecessarily smart. And share understanding of elegant code that is actually useful.<br /><br /><br />In the end per finished feature the code is on average more likely to be of higher quality, with more tests, more maintainable and properly solves the initial problem.<br /><br /><br /><br /><h3>Knowledge share</h3><br />One obvious benefit of pair programming is that now two people know everything about that task. And two or more now know about the product / system that the task involves.<br /><br /><h4>No single point of failure</h4><br />This reduces project, product and company risks and costs a lot. If one person goes on holiday or is sick there is no stoppage in working on that task or using that system as the other pair half can continue on his own.<br /><br />And worse if a person leaves the company or is hit by a bus there is no panic as multiple people know about that system or feature. Ideally if a person is off for longer period or permanently a new pair is formed quickly to remove the new temporary single point of failure threat.<br /><br /><h4>Best practices and showing scars</h4><br />Another good knowledge share benefit of pairing up is that the two people start to share best practices in approaches to implementation or even develop new ones. They share stories of previous scars of bad practices. This should make them both better developers.<br /><br /><h4>Rotate pairs - spread knowledge</h4><br />If you also continuously or with some frequency rotate the members of each pair you gain even more knowledge share.<br /><br />Product and system knowledge is now shared across the entire team. The risk of loosing knowledge is reduced further.<br /><br />Best practices are spread around the team. Members pick up new skills and enjoy sharing their experiences. The knowledge and quality increases, and team morale should also increase.<br /><br /><br /><br /><h3>Feature speed</h3><br />Initially the feature tasks and project speed may be slower if your team members pair program. In a mathematical sense it could be halved as it ties up two members per task. And the benefits of pair programming are often more longer term.<br /><br />But some implementations will go quicker as less likely to waste time on the wrong rabbit holes etc.<br /><br class="Apple-interchange-newline" /><h4>Speed per feature != initial implementation</h4><br />In the longer term a great increase in benefit is visible. If you count bugs, planning, etc as part of the actual total feature speed, a pair programmed feature is much more likely to be of higher quality and less likely to come back over and over again with bugs. And it is bug fixes that take time.<br /><br />The original implementation is often a low fraction of the total effort and time cost per feature. As Olaf describes in his "<a href="http://trustartist.com/2015/01/27/pair-programming-economics/">Pair programming Economics"</a>&nbsp;post, implementation is perhaps only 10% of the time spent on a task.<br /><br /><h4>Clean code</h4><br />In addition with good clean implementation the code is more maintainable making future extension and fixes much easier and quicker.<br /><br /><h4>Less procrastination</h4><br />There will also be less procrastination with dealing with issues, with talking to other people, etc as two people should drive each other on to finish a task.<br /><h4><br />Less wasted time&nbsp;</h4><br />When working on your own you may often spend a frustrating long time trying to figure out what is the actual problem, and how and where you should solve it. Sharing that with another person often cuts that waste down as it is quite likely one knows where to look already.<br /><br /><h4>Quicker ramp up and less resource bottlenecks</h4><br />If knowledge of a system of feature is already known by several team members if not all then starting a new related task can be ramped up quickly compared to starting on a feature or system you have never touched before. Shared knowledge also means there is no virtual bottleneck waiting for a person to be available to work on that issue if he is the only one that knows about it.<br /><br /><br /><h3>Not religious but no tricks&nbsp;</h3><br /><h4>Fake agile</h4><br />Many companies and teams say they are Agile but in reality they are not. “Being Agile” is not a black and white thing, it is a grey scale from non agile black to an unreachable white. Most projects are unfortunately quick dark grey even if they think and say they are Agile. Simply just using Atlassian’s Jira, having a daily standup, even some sort of iteration does not make you Agile. It is a lot more of fully adopting the practices and continuously try to come more agile.<br /><br /><h4>Fake pair programming</h4><br />The same goes with pair programming. Many say they do some sort of pair programming. Simple occasionally sitting together for a little while is not enough when most of the time they work by themselves.<br /><br />You need to commit to pair programming being the default convention for every tasks, for everyone. Set adaptable conventions on how to organise pairing. And when exceptions are acceptable, not the other way round.<br /><br /><h4>Shared responsibility</h4><br />Agile processes means not delegating and assigning tasks to individuals, but in the end team members pull tasks from the queue and make themselves responsible for that tasks. If they pair program that assignment is for both in the pair not one person. If it goes well, both get praised, if there is a problem both stand responsible. Similar to how the team shares praise and criticism.<br /><br /><h4>Personal space and time</h4><br />Another important step is to allow for personal space and time away from the other half of the pair. &nbsp;I don’t believe 100% pairing from 9am to 5pm is a good thing, no need to be in each others arm pits all day. That would cause friction and stress on the team. There is no need to be religious about it. Its a convention not a rule.<br /><br />Let people take breaks from each other. Much as Pomodoro Technique allows frequent breaks from work, pairs should take breaks from each other.<br /><br />They could spend that time on researching the tasks, perform mini hacky experiments. Watching another person google around for an hour is not that productive nor fun. &nbsp;Allowing people to catch up with IM chats and emails, make personal calls etc will allow for a more happy and productive pair when they pair up again.<br /><br /><h4>Non pair tasks</h4><br />Some tasks does not need to be paired up for. Simple research, monitoring, tiny typo fixes can be done by just one person. Having a nice balance of the majority of the time is spent on important paired tasks with a few smaller non paired tasks is probably a good idea.<br /><br /><h4>Effective onboarding</h4><br />Taking on new team members, recruiting junior members still have a great benefit from pair programming. Sarah Mei write a great article on the benefits of "<a href="https://devmynd.com/blog/2015-1-pairing-with-junior-developers">Pairing with Junior Developers</a>". Leaving new team members to plod along fixing bugs is definitely the wrong way to onboard them.<br /><br /><h4>Who to pair</h4><br />Probably out of scope and can cover an entire blog post but a tip is to mix pairs. Senior with juniors. Front end with back end focused skills. Testers with developers if appropriate. And also seniors with seniors.<br /><br /><h4>Remote challenge</h4><br />If the team is distributed pair programming does become a challenge. However it can still be achieved. Pragmatic Bookshelf have a great book on “<a href="https://pragprog.com/book/jkrp/remote-pairing">Remote pairing</a>” by Joe Kutner. And a lot of&nbsp;<a href="http://www.pairprogramwith.me/">tools and advice are available</a>.<br /><br /><br /><h3>Not for everyone but for most</h3><br />As I have shown here, I believe the pair programming is essential in a modern project. Sure, not pairing has worked for a long time and will still work. And for some specific teams and people it is still fine not to pair.<br /><br />But pairing works better with most teams. It reduces risk, it builds team culture, increases actual velocity, makes the team enjoy their work and in the end deliver much better products.<br /><br />Just approach pair programming with some common sense. It is not a factory, but don’t trick yourself into a halfway house either.<br /><br /><div><br /></div></div>flurdyI fully believe we can deliver faster projects, with better code, exposing less risk to the company and in the end be more profitable if team members pair program.The world was fine beforeThe world and businesses worked for thousands of years, even decades since computers was invented before agile methodologies took over how projects and companies was run. Projects was delivered and companies didn’t go bust.Workable products got shipped before testing was done thoroughly, before unit testing was common and TDD was even heard of.At the same time many teams worked well, developers wrote good code, meeting deadlines and shipping products before pair programming was a thing.Sort of..Were we also fine before cars replaced horses, computers replaced pen and paper, modern medicine replaced witch doctors?Before Agile projects was delivered often late, not meeting the updated requirements, and all the other benefits with Agile. But some was delivered on time with features as desired and to budget. Just fewer and a lot slower.And products were shipped with many bugs over and over again, with costly fixes over and over again.Why not pair?Double the resource costMany companies and managers can not see past the issue of using two people on one problem. Basically doubling the resourcing cost per story/task/whatever.And some (not many) are aware of the teachings of the Mythical Man Month&nbsp;that adding more resources to a problem is not a linear reduction in time to finish the problem.My space - my own thingMany people and developers are also not interested in working with others on a task, especially all the time. They feel their private space violated and interfering with their work habits. I/they/most people do like to think and experiment and solve a problem on their own. And be trusted to do so.Being forced to sit and watch, to talk to another person about every step of solving a problem is a big change in work habits and social skill requirements.So why pair program?3 reasons: Code Quality, Knowledge Share and Feature Speed.Code qualityMini planIf two people sit together to work on a task they are quite likely to discuss the issue and basically perform a mini up-front architecture analysis of the problem. They might even apply TDD approach to solving it. In essence it should deliver a slightly more thought out solution than simply jumping in the deep end and hacking out a solution.Human rubber duckExplaining the problem and solution to a human rubber duck also unveils the root cause and the better solution much quicker.Less rabbit holesTwo people are less likely though not guaranteed to go down a completely wrong rabbit hole in solving the problem. And at least quicker to realise that they are and pull out out sooner.No short cutsIf you sit with someone you are less likely to cut corners and take short cuts in your approach and implementation. This is a very good reason for why pair programming results in better code quality. You are for example less likely to skip writing tests if someone sits with you.Less mistakesSimple mistakes and syntax errors are quickly spotted and corrected. Human compiler and typo spotter is often what happens but that is not really a bad thing, just don’t be offended by it.Clean readable codeBy having two people agree on the implementation then the readability and approach to the code should be cleaner and more maintainable as you both have to agree and understand the delivered implementation. This basically negates the need for extensive code review process later on as covered in my "Pair with people you like and code reviews with people you don't like"&nbsp;blog postNinja codeA lone developer often so called ninjas may also try to write smart code. Code that none else can understand nor maintain when that person leaves. A pair would prevent writing code that is unnecessarily smart. And share understanding of elegant code that is actually useful.In the end per finished feature the code is on average more likely to be of higher quality, with more tests, more maintainable and properly solves the initial problem.Knowledge shareOne obvious benefit of pair programming is that now two people know everything about that task. And two or more now know about the product / system that the task involves.No single point of failureThis reduces project, product and company risks and costs a lot. If one person goes on holiday or is sick there is no stoppage in working on that task or using that system as the other pair half can continue on his own.And worse if a person leaves the company or is hit by a bus there is no panic as multiple people know about that system or feature. Ideally if a person is off for longer period or permanently a new pair is formed quickly to remove the new temporary single point of failure threat.Best practices and showing scarsAnother good knowledge share benefit of pairing up is that the two people start to share best practices in approaches to implementation or even develop new ones. They share stories of previous scars of bad practices. This should make them both better developers.Rotate pairs - spread knowledgeIf you also continuously or with some frequency rotate the members of each pair you gain even more knowledge share.Product and system knowledge is now shared across the entire team. The risk of loosing knowledge is reduced further.Best practices are spread around the team. Members pick up new skills and enjoy sharing their experiences. The knowledge and quality increases, and team morale should also increase.Feature speedInitially the feature tasks and project speed may be slower if your team members pair program. In a mathematical sense it could be halved as it ties up two members per task. And the benefits of pair programming are often more longer term.But some implementations will go quicker as less likely to waste time on the wrong rabbit holes etc.Speed per feature != initial implementationIn the longer term a great increase in benefit is visible. If you count bugs, planning, etc as part of the actual total feature speed, a pair programmed feature is much more likely to be of higher quality and less likely to come back over and over again with bugs. And it is bug fixes that take time.The original implementation is often a low fraction of the total effort and time cost per feature. As Olaf describes in his "Pair programming Economics"&nbsp;post, implementation is perhaps only 10% of the time spent on a task.Clean codeIn addition with good clean implementation the code is more maintainable making future extension and fixes much easier and quicker.Less procrastinationThere will also be less procrastination with dealing with issues, with talking to other people, etc as two people should drive each other on to finish a task.Less wasted time&nbsp;When working on your own you may often spend a frustrating long time trying to figure out what is the actual problem, and how and where you should solve it. Sharing that with another person often cuts that waste down as it is quite likely one knows where to look already.Quicker ramp up and less resource bottlenecksIf knowledge of a system of feature is already known by several team members if not all then starting a new related task can be ramped up quickly compared to starting on a feature or system you have never touched before. Shared knowledge also means there is no virtual bottleneck waiting for a person to be available to work on that issue if he is the only one that knows about it.Not religious but no tricks&nbsp;Fake agileMany companies and teams say they are Agile but in reality they are not. “Being Agile” is not a black and white thing, it is a grey scale from non agile black to an unreachable white. Most projects are unfortunately quick dark grey even if they think and say they are Agile. Simply just using Atlassian’s Jira, having a daily standup, even some sort of iteration does not make you Agile. It is a lot more of fully adopting the practices and continuously try to come more agile.Fake pair programmingThe same goes with pair programming. Many say they do some sort of pair programming. Simple occasionally sitting together for a little while is not enough when most of the time they work by themselves.You need to commit to pair programming being the default convention for every tasks, for everyone. Set adaptable conventions on how to organise pairing. And when exceptions are acceptable, not the other way round.Shared responsibilityAgile processes means not delegating and assigning tasks to individuals, but in the end team members pull tasks from the queue and make themselves responsible for that tasks. If they pair program that assignment is for both in the pair not one person. If it goes well, both get praised, if there is a problem both stand responsible. Similar to how the team shares praise and criticism.Personal space and timeAnother important step is to allow for personal space and time away from the other half of the pair. &nbsp;I don’t believe 100% pairing from 9am to 5pm is a good thing, no need to be in each others arm pits all day. That would cause friction and stress on the team. There is no need to be religious about it. Its a convention not a rule.Let people take breaks from each other. Much as Pomodoro Technique allows frequent breaks from work, pairs should take breaks from each other.They could spend that time on researching the tasks, perform mini hacky experiments. Watching another person google around for an hour is not that productive nor fun. &nbsp;Allowing people to catch up with IM chats and emails, make personal calls etc will allow for a more happy and productive pair when they pair up again.Non pair tasksSome tasks does not need to be paired up for. Simple research, monitoring, tiny typo fixes can be done by just one person. Having a nice balance of the majority of the time is spent on important paired tasks with a few smaller non paired tasks is probably a good idea.Effective onboardingTaking on new team members, recruiting junior members still have a great benefit from pair programming. Sarah Mei write a great article on the benefits of "Pairing with Junior Developers". Leaving new team members to plod along fixing bugs is definitely the wrong way to onboard them.Who to pairProbably out of scope and can cover an entire blog post but a tip is to mix pairs. Senior with juniors. Front end with back end focused skills. Testers with developers if appropriate. And also seniors with seniors.Remote challengeIf the team is distributed pair programming does become a challenge. However it can still be achieved. Pragmatic Bookshelf have a great book on “Remote pairing” by Joe Kutner. And a lot of&nbsp;tools and advice are available.Not for everyone but for mostAs I have shown here, I believe the pair programming is essential in a modern project. Sure, not pairing has worked for a long time and will still work. And for some specific teams and people it is still fine not to pair.But pairing works better with most teams. It reduces risk, it builds team culture, increases actual velocity, makes the team enjoy their work and in the end deliver much better products.Just approach pair programming with some common sense. It is not a factory, but don’t trick yourself into a halfway house either.