At the excellent Agile Manchester conference recently, I picked up a copy of the latest Technology Radar (Vol.16 – March 2017) from our friends at ThoughtWorks. Several things in this version stood out for me, most of which are really about how we use technology rather than specific technologies in themselves:
- Developer Experience
- API as a Product
- CodeScene for software forensics
- Single CI instance as a bad thing
- Spring Cloud for simplifying operational techniques
Developer Experience as the new differentiator
Making tools and software feel good to use can really help with the adoption and evolution of new technology. By identifying ‘developer experience’ as important, we start to consider things like deployability, configurability, testability, etc., all of which contribute to making better software. I touched on this in my talk at QCon London in March 2015 about Continuous Delivery, tools and Conway’s Law:
A focus on the developer and tester experience also helped us recently to improve the software release outcomes for IDBS, one of our clients in the pharmaceutical sector. By starting with the needs of the team members, we were able to drive effective conversations and discovery around how people wanted to experience the software as they developed, tested, deployed, or released it.
API as a Product
When we consider the likely effect of Conway’s Law on software architecture, we should expect to take care when aligning teams to boundaries like APIs. In fact, in my workshop on organisation design for effective software, I recommend starting with separate teams for the API and the consuming software, as this is a simple way to help keep the development of an API more holistic and healthy. I often find that organisations have put in place a ‘product owner’ for the user-visible parts of their software but have neglected to treat the underlying platform or API as a product, leading to misunderstandings, poor or degrading software quality, and delays.
If you were consuming a public SaaS-hosted API, you would (I hope) expect it to have a roadmap, good documentation, and nice and stable API endpoints. We can take this expectation and bring it into the organisation: even if a team is developing an internal API, they need a product owner, a roadmap, good developer documentation, and an appropriate versioning scheme. Treat the internal dev teams that consume your API as if they were paying customers!
CodeScene for software forensics
I am a huge fan of the work of Adam Tornhill, especially his book Your Code as a Crime Scene. Adam has real-life experience in forensic pathology AND writing compilers and code analysis tools: what a combination! In my talk at Velocity EU 2016 on teams and monoliths, I explained how Adam’s tool Code Maat can be used to analyse a codebase for hidden temporal coupling, something hugely valuable when considering whether to split a repository into smaller pieces.
Adam is CTO at Empear AB, creators of Codescene, a SaaS tool that does code forensics as a service. Codescene enables really rich conversations about our code, conversations based on actual code and commit-history analysis rather than guesswork. I pointed Codescene at a fork of the GoCD repository on Github as a way to test out its features. The Hotspots feature is rather nice, showing where in the code is the most churn and therefore probably the next bug! (click to enlarge):
However, the most striking feature for me of Codescene is the Teams feature. Although Git is a great version control system, its understanding of groups of people is pretty limited; Codescene uses the Teams feature to try to show how different teams in the organisation are interacting with the codebase. This is super useful for discussions about ownership, refactoring from monoliths to microservices, and all sorts of other situations. For example, Codescene can show which artifacts suffer more parallel development by teams.
Single CI instance as a bad thing
We often encounter organisations that have not really invested very much in build & release engineering: version control, packaging, CI, deployment pipelines, etc. (in fact, this is one of the “Continuous Delivery anti-patterns” we have spoken about). In many cases, a very small team (sometimes just one person) has been left to support build & release infrastructure for many dev teams, leading to a need to optimise for manageabilty of that infrastructure. The different dev teams are stuck struggling with a single flaky continuous integration (CI) tool that does not really meet their needs. We certainly should not blame the people trying to look after the infrastructure (I have been one of those people myself) but instead look to other options for giving dev teams a better developer experience.
One solution we have been exploring at Skelton Thatcher Consulting is the use of Rancher for creating and maintaining per-team build & deployment infrastructure (particularly GoCD). It turns out that Rancher is particularly good at this, partly due to its Catalog concept, providing a simple way to specify which tools and services to make available for teams to deploy:
We realised that if dev teams rely on a single, central tool for some aspects of software delivery they tend to feel blocked and/or disengaged from making changes. If they can own their own infrastructure for deployments and testing, they can improve things more quickly without having to rely on a central team. Enabling this improved developer experience of course needs investment and – crucially – a good social contract between the dev teams and the build & release team.
Spring Cloud for simplifying operational techniques
As software systems become more and more distributed, the need to address real operational concerns also increases. It’s great to see a framework like Spring Cloud address operational challenges by simplifying things like service discovery, load balancing, circuit breaking and health checking. Simple HTTP 200/500 health checks are some of the most straightforward changes any team can make to improve their software’s operational efficiency. Having this feature almost out of the box in Spring Cloud should really help teams to “get it right”.
Note: I am co-authoring a book called Team Guide to Software Operability which covers many aspects of operational readiness for software systems.