As a ThoughtWorks consultant, I was sent to clients to assess the way they developed software and present the findings back to them. Sometimes I did this solo, and sometimes as a team. My focus was always the foundational aspects of development. In the mid-2000’s if the assessment was titled at all, it was called an Agile assessment. After Jez Humble and Dave Farley’s best seller Continuous Delivery (2010) the assessment was expanded and re-titled to a CD Assessment. Same again in 2013, expanded and retitled to DevOps Assessment. I’m veteran of 20 or so assessments, amongst the general leadership of application development and delivery for clients that I have done over the years.
I am part of the science and history of DevOps
I’m also a pivotal part of science. I’ve always evangelized Trunk-Based Development (TBD) and joining ThoughtWorks in 2002 let me turn my Agile (Extreme Programming) interest/hobby into something I was paid to do every day. I evangelized TBD inside TW too and flipped all of my clients to that branching model soon after being staffed on each account. In 2005, I assessed, presented the resulting findings, then started at Bank of America’s Global Foreign Exchange (GFX) group in Chicago. The team was using ClearCase in a multiple long-running branch scenario, and it took a lot of choreography to pull a dev team of 100s into Trunk-Based Development without dropping a release, or cutting scope. In fact, the migration was multi-faceted and documented here, and a huge personal achievement for me.
🔗Branch by Abstraction
Part of that Bank of America GFX migration, involved the creation of technique to counter the pressure to create a long-lived branch that would merge “back” later. It has been widely documented since, but I wrote the first blog entry on it (and the name has stuck) . Most likely the technique was already in use elsewhere, sporadically, but not documented. So I did not invent it as such, just put it on the map. Jez and Dave included the artwork I made for the Bank of America GFX mission and blog entry in their “Continuous Delivery” book. Martin Fowler went on to write an article on the practice too, that really boosted its popularity.
Lastly on this, I have an informational portal that attempts to describe the practice in one sitting: BranchByAbstraction.com.
🔗Trunk-Based Development (again)
So I blog a lot about TBD. Forty articles to be precise. ThoughtWorks placed me at Google for 20 months in their Test Mercenaries team, and I got to see a TBD implemented at a scale I had only imagined in the previous years.
Jez, to this day, likes to rabble-rouse with statements on Trunk-Based Development (that I completely agree with):
after 10 years of giving talks on this, trunk-based development is still the idea that causes most controversy today! pic.twitter.com/5EK7LQgvkh— Jez Humble (@jezhumble) October 17, 2016
It remains the big unlearned lesson of high-throughput DevOps-centric teams, and widely misunderstood. That Google, Facebook and many other lauded companies do TBD at scale is lost on most people in the industry, and many even in the DevOps community. Indeed ThoughtWorks placed me at Google in 2007, and I was pleased to discover the world’s biggest Trunk-Based Development setup, as well as incredible DevOps. Before starting there, I quickly pushed out the "Introducing Branch by Abstraction" 2 blog entry just in case Google controlled the blogging of development staff (and consultants).
My leadership on Trunk-Based Development, saw my materials included in the “Continuous Delivery” book (with acknowledgment). Also, Jez’s following book - “Lean Enterprise” (with Barry O’Reilly and Joanne Molesky) features some of my materials in an attempt to catalog developer team practices associated with Trunk-Based Development. I’m also mentioned in Jez’s most recent book (with co-authors Gene Kim, Patrick Debois, John Willis) “The DevOps Handbook”, but only in passing and to do with “Application Strangulation case studies”.
And to underline, all these references, nobody has written more than me on TBD and branch by abstraction, or as long as I have on those topics. With friends, I made an informational site to pull all of the related topics together: TrunkBasedDevelopment.com.
I got to see first hand how Google organize their expanding/contracting monorepo for unbeatable DevOps performance. At lot of my blog entries are attempts to teach the DevOps lessons that I learned while at Google. A decent chunk of my consulting into companies concerns this directly, and how to help the company in question transition to that, avoid pitfalls, and realizing savings after roll-out.
🔗Other innovations and firsts
I am co-creator of the defacto-standard web testing technology, Selenium in 2004. That was v1, with Jason Huggins, and we very early open-sourced it to begin the log slog to gain industry patronage. Selenium is at v3 now and a multi-million dollar industry on its own. It has long since eclipsed QTP in importance, and long since deleted our last lines of code from the v1 days. It is definitely a pivotal DevOps tool.
🔗PicoContainer and Dependency Injection
I am co-creator of the first Dependency Injection (DI) container that did “Constructor Injection” called PicoContainer (in any language) in 2003. The other co-creator was Aslak Hellosøy who’s more famous for being the lead developer of the defacto-standard Cucumber BDD technology these days, as well as co-founder of a startup around it. Indeed, towards that, I was chief evangelizer of “Inversion of Control” (IoC) inside ThoughtWorks before Martin Fowler published his highly influential article “Inversion of Control Containers and the Dependency Injection pattern”. That article effectively renamed IoC to DI. Note my name at the bottom of Martin’s article.
Of course these days, we all like the practice of using constructors for passing dependencies into components (rather than shared static state), but not as much the containers. At least not as much as we did back then.
🔗Legacy Refactoring: Least depending, most depended on first
🔗Test Impact Analysis towards running fewer tests
If you have 1000 tests taking 10 seconds each, or 10000 tests taking 1 second each, that is 2.7 hours to execute them all. At HedgeServ, I introduced a mechanism to determine which tests are provably impacted for a given commit, and how to shorten the duration of tests because of that. It relies on code-coverage being pre-calculated on a per test basis and from that a map of code vs tests that can be used to speedily perform the test reduction. I blogged on this providing Java  and Python proofs of concept. Microsoft is also talking about the same ideas , .
🔗Configuration as Code
This is a new aspect of application development that pertains to teams that are constrained on their release cadence, but want to make controlled changes to the production changes between releases. Perhaps they are a financial services company and need audible sign-offs for each release. The concept is that there is a category of configuration that can be represented in JSON (etc) and stored canonically in VCS. This would be a separate VCS to that of the application’s code, and be subject to different controls. The novel aspect to the prototypes I’ve been sharing with clients since 2012, is the “round trip editing” capability. That is where the’re a simple editing form in a web page for the configurable item (that saves to VCS), and the ability for power users to edit the JSON directly as they would any other source document under source-control. I have five or so real demonstrations of the technology that clients can pick from when choosing their approach to this.
🔗Client Side MVC
Because of a friendship with the authors of Angular, I was able to prepare and push a blog entry on it the same day as Miško Hevery announced the tech for the first time on his blog  in 2009. Ever since I have been a huge fan of its terse & expressive style, and the stroke of genius that extending HTML was. I’ve written 29 blog entries on "Client Side MVC" since then, all focused on the potential for development cost reductions that this class of technology heralds (if done right). As an application technology choice, there’s definitely a DevOps benefit.
Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (published Aug, 2010) ↩ ↩
Inversion of Control Containers and the Dependency Injection pattern (Jan, 2004, Martin Fowler’s site) ↩
Refactoring Experiment - ‘least depending and most depended on’ components first (Sep, 2011, my blog) ↩
Reducing Test Times by Only Running Impacted Tests (Jan, 2015, my blog) ↩
Reducing Test Times by Only Running Impacted Tests - Python Edition (Jan, 2015, my blog) ↩
Accelerated Continuous Testing with Test Impact Analysis – Part 1 (Mar, 2017, MSDN) ↩
Accelerated Continuous Testing with Test Impact Analysis – Part 2 (May, 2017, MSDN) ↩
Angular - HTML based Declarative UI (also one to watch) (published Sep, 2009) ↩