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 bestseller 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 “Big Four” bank’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 “Big Four” bank 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 Big Four bank’s FX 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 likes to rabble-rouse with statements on Trunk-Based Development. Here’s one from 2016 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!” Jez has deleted his Twitter account, but it used to exist here, in case it ever comes back.

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 the related topics together: TrunkBasedDevelopment.com.

Monorepos

I got to see first hand how Google organize their expanding/contracting monorepo for unbeatable DevOps performance. A 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

Selenium v1

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 key test automation tool, and changed the game when it came out

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

This approach to a large refactoring agenda came out of my “Big Four” bank mission. I first documented it for InfoQ in 2008⁷. It was referenced in a follow-up “refactoring experiment” article⁸, and updated and made into a PDF in 2013⁹. Actual animations from the “Big Four” bank FX recommendation deck were redone in JavaScript and SVG for a blog entry on “tweening” in 2016 for fun¹⁰.

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 ^13,14.

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.