Session type: Bonus
James Lewis – Building systems that are #neverdone – Live Blog 2015
James Lewis is a Principal Consultant for ThoughtWorks. He’s a developer and coach introducing evolutionary architecture practices and agile software development techniques to Investment Banks, Publishers and media organisations. You can catch up with James at his website and on Twitter.
James is made of eyes!
What is never done?
It’s not building systems that are unfinished, instead systems that are always improved upon and iterated. Systems are built in chunks of code that can be built and replaced in small chunks.
Netflix is an example of an organisation that are continuously changing their software without the end user noticing.
More and more companies started to do things differently. this allows then to deploy smaller releases more often. Teams can scale independently of each other and can operate at web scale when needed.
Small startups can adapt and change quicker than enterprise organisations. By creating smaller teams and ‘chunked’ software larger, named micro services, they can adapt quickly and effectively.
With continuous deployment and only one environment, how do we check that the deployed software works as intended and is tested fully? Which micorservices make up the end product?
Locks are one way, but are inefficient.
Amazon web services is another possible solutions, but is buying into a platform the right way to go about it? It does allow as many integration pipelines as needed. This is fine until the monthly bill rolls in.
With all the tools available, where do we start and do we really need this potentially high level of complexity. One solution is to only build the services needed when needed, however this is not always suitable for ‘legacy’ systems.
By using well established design principles, e.g DRY, GRASP. James suggests that whilst a service should be DRY, there can de duplication between services, making them self contained.
Should we bother with test driving our code if we are going to throw it away
The Dreyfus model of skill acquisition:
The software created by a novice and expert will differ greatly, with the decisions being vastly different between the two.
Should I use TDD? Unless you’re Kent Beck, Yes.
A single class of code should be understandable in its entirety. It should be containable in our heads and the size of a head.
We should always do the simplest thing possible. Always.
This helps problems to be detected, identified and fixed in the shortest time possible. This results in minimal impact to the end user / customer.