Technical practices of XP such as TDD, Refactoring, CI and Pair Programming support emergent design and enable evolving your architecture. The first practice you need for continuous delivery is CI, committing to mainline every day. Being able to write clean, well factored, well tested modular code is the most important skill for developers.
Rachel Laycock, head of technology for North America at ThoughtWorks, spoke about technical practices in agile at Agile Summit Greece 2017. InfoQ is covering this conference with Q&As, summaries, and articles.
InfoQ interviewed Laycock about evolutionary architecture, continuous delivery, and technical skills.
InfoQ: What practices do you recommend for evolutionary architectures? Why these?
Rachel Laycock: Evolutionary architecture introduces some new principles like making architecture decisions at the last responsible moment, using fitness functions to test your architectural decisions and bringing pain forward. This last principle is actually adopted from eXtreme programming, the theory being if something causes pain, do it more often. This usually leads to improving the process of automating it in someway so it’s no longer painful. This is exactly where continuous delivery came from. The pain of a long wait time to set up environments and deploy to them was removed by trying to deploy more often. In doing so, new tools were created to build environments and deploy to them, and challenges that slowed things down like governance processes were automated. Making deployment an uneventful click of a button vs an entire weekend event. All because the pain was brought forward.
In spite of the new principles, the practices of continuous delivery and XP remain relevant and necessary. Underlying characteristics like building incrementally, modularity and organising around business capabilities and experimentation are key. But the technical practices of XP such as TDD, Refactoring, CI and Pair Programming support emergent design which is key to being able to evolve your architecture as you go. As your architectural decisions are made as and when they are needed at the "last responsible moment", you need modular, well-tested code the whole team understands to change with them, and you get that from the practices of XP. To me, the practices of continuous delivery and XP are an "and", not an "or" where you are employing the principles of evolutionary architecture.
InfoQ: What practices have proved to be most valuable in continuous delivery?
Laycock: The practices of XP underpin continuous delivery. One of the first places people often start on their journey to CD is with creating a continuous integration server and a pipeline. This is just a tool, the practice of CI, committing to mainline every day is the first practice you will need. But you need to have trust in the code committed, it’s quality and if it is free from error and for this you need a suite of tests. If you are applying continuous delivery after the code is written or you’re in a legacy code situation, then often the tests are not there, so this becomes the most fundamental problem to tackle. Instances where I see code written in a clear understandable way is often written with the practice of TDD.
CD solves the last mile problem, and with it new tools were introduced to create and store configuration management of environment and deployments. But in the ecosystem supporting these tools, you can and should be writing tests. Often you can TDD the code you write for configuration management, so fundamentally the underlying practices don’t change even here.
InfoQ: What are the most important technical skills for developers?
Laycock: Being able to write clean, well-factored, well-tested modular code is the most important skill. Really understanding the challenges of coupling and cohesion. After that you can apply the nuances of your language, but languages will change whereas these fundamental skills have not.
InfoQ: How can developers sharpen their technical skills?
Laycock: They key is practice, practice, practice. Learning TDD is hard, but if you practice you will get better at it until it becomes the norm for you. Then and only then will you have the ability to make a pragmatic decisions as to whether you TDD your code or not. In general, I believe you should as it enforces - if you are doing it right -the practice of refactoring which is important to not creating "legacy" or balls of mud in the future. Balls of mud that will inevitably slow you down.
InfoQ: What can developers do to stay on top of new developments in technical practices?
Laycock: With the introduction of CD and DevOps, technical practices at the core have not changed much. Once you learn them you can apply them to software design and architecture you pursue, such as domain driven design, REST, and evolutionary architecture.
