I find the bias claim an odd critique. I am of course biased -- in the appropriate context (e.g., architecture), bias is just another word for "judgment" -- but I don't think a claim of commercial bias is a strong argument.
It is true that my company (Thoughtworks) is primarily a custom software delivery firm, but the point you might not have awareness of is that many (and most or all of the large) software services firms choose to build capabilities in low code platforms (in the past year alone, I've worked with Accenture and BCG Digital Venture Mulesoft experts and EY around Pega). In fact, many of the larger services firms get EXTRA commercial lift through partnerships with those low code companies ("finders fees"). We could easily do the same, make good money in the process, and take on a broader book of business in doing so.
I'd have an easier time buying a related critique that neither I nor the colleagues I spoke to in shaping the article have exposure to other contexts where low code integration tools are the right choice. If you have some, I'd love to hear them.
Why do I have the opinion that ThoughtWorks is better than Accenture (or EY, Deloitte, etc)? Do they pay more for talent?
About half the projects I see come out of non-boutique consultancies are shit. Actually, no. More than half lately. Probably 80%. I work in a role that exposes me to a wide range of partner-led engagements across large enterprise, but I admit my role is limited by region.
ThoughtWorks on the other hand is massive, and seems to pick and choose engagements a lot more. They also seem to stack their teams with relevant talent. If they're assigning juniors or mid-level devs, they almost always seem to get some oversight by someone with a lot of relevant experience and input before going live.
Well, I'll make no pretense that my answer here isn't commercially biased :)
To the easy point first: you're right about providing oversight to juniors and mid-level devs. We generally avoid selling "staff augmentation," as that doesn't allow oversight or outcome accountability. Selling teams helps give our clients more confidence in delivery and helps us provide a range of experience on the team (which obviously helps with cost). We also have a very robust grad hiring program and onboarding curriculum to help skills-based training for junior developers.
As for the rest of it, Thoughtworks is growing but isn't massive (think roughly 1/30th the headcount of a Deloitte). I'm not an expert on compensation, but I would say that 1) we're competitive, and 2) comp probably isn't the reason behind your perception. More likely, it is the history of quality delivery and thought leadership.
Given our relatively small scale, it is certainly true that Thoughtworkers have had an outsized impact on the technology industry. Notice the word choice: "Thoughtworkers," not "Thoughtworks". Jez Humble and Dave Farley wrote the book on Continuous Delivery (at the time, Jez still worked here, Dave had moved on from the company). James Lewis and Martin Fowler wrote the definitional article on microservices, then Sam Newman wrote the first book before leaving the company. Zhamak Dehghani wrote the first article on data mesh and is wrapping up the book. While there have been a few books directly sponsored by the company, they are often not as impactful as passion projects by individuals, a pattern that started early on with open source (Cruise Control, Selenium, NUnit, DBMigrate, etc). We have a business model where the company benefits by helping individuals build their personal brand, and with folks like Martin Fowler to help provide a loudspeaker, it's a compelling value proposition for technologists who want to make an impact. I suspect that's a bigger talent value proposition than comp.
Of course we do marketing, but the reason I pushed back on the critique of commercial bias is based in both an understanding of the technology services industry (stated in the post above), and an under-reported appreciation of Thoughtworks culture. Those passion projects aren't generally vetted by the company, but many are promoted by it -- if you do the work to create something noteworthy, the company will help you get the exposure. Sometimes, it's individuals and not the company itself. For example, Paul Hammant, who has a good personal brand based on his work spinning up Selenium and PicoContainer during his tenure at Thoughtworks, helped promote my own open source tool (mountebank) several years back. The tool has a spot on the company open source page, but Paul's evangelism was what led to an acquisition editor calling me up about a book offer. Similarly, my integration article is published on Martin's personal site, not a company site (although we have that too, and do support employee writing contributions). I assure you that for this type of article, Martin's editorial filter is based on what he considers quality opinions and writing, not Thoughtworks marketing, and he welcomes non-Thoughtworker contributions as well. The same sensibilities are even common when the artifact IS corporate-sponsored. I'm part of the group that curates the Thoughtworks Technology Radar, for example, which is a pretty popular marketing artifact. Rebecca Parsons, our global CTO, is adamant to all of us that you cannot buy your way onto the radar, and that same principle applies to internally produced technology or thought leadership: we are not there to directly promote Thoughtworks; we are there to curate our opinion on technology trends regardless of where they originated. Marketing Thoughtworks becomes a side effect, not the focus. That is a very different approach to marketing compared to other technology companies I've been exposed to. We encourage filtering good advice through the marketplace of ideas based on influence and networking and feedback, not through corporate-sponsored dictates.
That autonomy leads to a rejection of common "markitecture" approaches. An analogy I sometimes use is that of magicians. It is far too common in our industry for companies to sell smoke and mirrors hiding behind proprietary tooling and language meant to make things sound more complex than they are. They are like stage magicians: it's great when it works, but it doesn't help anyone else repeat the same trick -- understandably, because giving the trick away gives away a perceived competitive moat. There is a different path, though. Penn and Teller are world-class magicians, but they are also famous for telling you exactly how the trick works while they're doing it. The audience is left with something more than wonder: understanding and appreciation that skill, not magic, is behind the trick. That means Penn and Teller need to be willing to continue to improve their craft and innovate to stay competitive as there are no secrets to protect their revenue model. Thoughtworks-the-company encourages Thoughtworkers-the-individuals to give away thought leadership and innovations to the industry, and relies on the brand equity that creates to attract the talent needed to deliver and come up with the next innovations. It is a strategic bet that our customers care about the craft of software development itself.
So, yes, talent is key, but culture trumps compensation.
Good feedback. Most of the article is about integration inside an enterprise, although in the next installment I do talk about integration between organizations (hint: there are scenarios where I think low-code tools make sense there).
There are some excellent HTTP/S stubbing libraries out there but no open source ones that let you also stub other protocols. mountebank was first built to support testing Java serialization over a mule-based TCP layer, supports HTTP/S, SMTP, and I'm working on first-class SOAP support. The only tools that provide this capability today are commercial (e.g. CA Lisa) and not nearly as friendly to CI/CD practices.
By the way, thanks for this thread. Independently of my own self-promotion, it's a great idea. Great open source developers are rarely good marketers, which means the best tools often rot in obscurity, and users of the tools rarely recognize that they can help by the simplest of actions. Find the ones you like on this page, star them, fork them, link to them. Help the open source community shine.
mountebank could support that through stub resolver injection (http://www.mbtest.org/docs/api/injection). Basically, in addition to returning a response, you can inject some javascript that would call back after some time. Tricky, but possible.
I think some level of integration testing is always a good thing, but spinning up all dependent services just so you can test yours leads to all kinds of problems, even in microservices. You end up with cascading dependencies.
At scale, some level of stubbing is required to test.
We _partially_ solve this problem by letting you run a dev cluster that you can use for services which are awkward to run locally, but stubbing/mocking definitely has a place in automated testing, certainly.
Should we have said nothing? For the past several months Aaron has led the development of an online petition application working with several senior programmers at ThoughtWorks for a project we paid for ourselves, because we believed in his cause, and we believed in Aaron. Friends of Aaron who worked with him built rememberaaronsw.com because they are hurt and they wanted to honor the man in the best way they knew how. This wasn't a group of people trying to capitalize on a public figure. This was his friends and colleagues.
I'm sorry if this came off the wrong way to you, but you should realize that the message of internet freedom doesn't necessarily help us sell our services in a lot of places.
For me, that last paragraph ("About Thoughtworks") is what left a poor taste in my mouth. Up until that point, I personally thought it was in good taste. If someone doesn't know who ThoughtWorks is and needs to know, I assure you that they'll find it via a search engine. I'd also drop the contacts phone numbers as well.
The addition of that About TW paragraph, no matter how "standard" in a PR setting, is incredibly inappropriate in my view and makes it appear that you are taking the occasion of an employee's suicide to market ThoughtWorks. Don't do that.
Try to see it from the other side. The "About Thoughtworks" is just how companies talk.
The fact that it looks exactly like an official ThoughtWorks PR broadside makes it even clearer which side the company is on. No "this is the private opinion of colleagues/friends", but "this is how strongly the company feels about this".
Understood, but it looks like the About ThoughtWorks section is just part of the press release template (look through the previous press releases and you see the same thing). I don't think our website team was prepared with a template for this kind of statement.
It is true that my company (Thoughtworks) is primarily a custom software delivery firm, but the point you might not have awareness of is that many (and most or all of the large) software services firms choose to build capabilities in low code platforms (in the past year alone, I've worked with Accenture and BCG Digital Venture Mulesoft experts and EY around Pega). In fact, many of the larger services firms get EXTRA commercial lift through partnerships with those low code companies ("finders fees"). We could easily do the same, make good money in the process, and take on a broader book of business in doing so.
I'd have an easier time buying a related critique that neither I nor the colleagues I spoke to in shaping the article have exposure to other contexts where low code integration tools are the right choice. If you have some, I'd love to hear them.