You Can't Buy Integration
martinfowler.com
martinfowler.com
If you don’t have a culture of code review then maybe the rewrite will fly, bugs and all, through to production. If however you have the ability to reason logically about the salient changes diff by prescient diff — where by definition each prescient diff represents nothing but the salient changes — then you at least stand a fighting chance of version N+1 having fewer bugs than version N while also moving your business forwards.
Anything else is a quagmire that will never converge on stability and it all starts with there being a 1:1 mapping between what you think and what you write. Java is particularly unforgiving for code where ones thoughts are unclear.
As a complete aside: buy your dev team a fountain pen and a pad of paper for Christmas. Writing meaningfully is everything.
The real challenge of programming is how you organize a million if statements in a way that the system can be understood and evolved predictably and cheaply over time.
And any tool that takes away the control of how you organize your code and allows for the creation of complexity without proper version control, debugging, testing and code review is doomed to failure.
No code is just code at a higher level of abstraction. No code works when you don’t need a lot of code to solve the problem to begin with. Which is kind of a mind bender.
It’s roughly as useful as pointing out that constructing a skyscraper is really just applying forces to masses.
Why is Java bad that way? Overly complex classes? In my experience, C++ is particularly awful, since careless programming can lead to memory corruption, use-after-free, and nonlocal malfunctions and crashes.
If nothing in the architecture can just be a free-floating procedure, not even a pure function, the system architecture will evolve around this
- Store data
- Simple convenience functions that tell me about its state
- Side-effect-free mutations (or data massaging) that have no external dependencies other than function params
- Simple validation, if there are no external dependencies
Everything else goes in a service/function.
One anti-pattern/code smell I often see is finding classes in a service which should just be a functionally pure pipeline (eg. no internal state is managed)
That has never sat well with any kind of source control where you are expressing your ideas with line oriented patches.
I only code with JavaSE and only use 2 external dependencies (original json and dns4j, both minimalist and written by one man each), that said Java probably has the leanest API that has ever existed and potentially that will ever exist.
This is a good critique of low-code/no-code in general. The root problem I see of "Unfortunately, when we frame the problem space that way, we have allowed our tools to think for us." is that in reality there are just not enough qualified software engineers out there.
Mind you I've been building SPA's since they weren't "a thing" and today I mostly use Vue.
But for that role, they didn't like my lack of .env variables in the front-end (such as for things that end up in the HTML), after a 3 hours coding test, and a couple of minor React-y tid bits they couldn't even clarify. Basically, not "idiomatic".
Meanwhile, none of them could tell me how React actually works, beyond throwing jargon vomit. They couldn't write a web application without React. The recruiter, which we had to go through, basically had no empathy and saw me as a failed resume. I felt pretty helpless, even though I've said many times to both parties that I wasn't a "React developer".
That is the sad state of affairs today; and I'm finding it's not just in the front-end, where you could argue that you need sanity on this pile of rubbles. It's also in the backend, especially on the auto-magic "DevOps!"
On the other hand I think it is a natural progression. 30 years ago experienced engineers would look at young people who didn't know how to fix a PCB or read bytecode and think it was a shame. If everyone had to get a computer engineering degree and work at several different roles before they could even build a UI, that would be bad for productivity.
I think about that often when I think about all the things I don't understand about hardware and EE.
I'm actually thinking that at some point, no one will be building custom software. Everything will be available off the shelf, as some product, running on some cloud within a few clicks.
So "custom software" developers are a dying breed.
For example, when Jira is down, a Jira "specialist" will tinker and bring it back and look like some guru walking down the mountain of knowledge. Arguably, this person probably wouldn't know anything about SIMD. Yet the SIMD guy is looking for a job, no one cares about that guy. But the "salesforce developers" and "Jira specialist" are permanently employed at very high wages.
I have soldered chips to boards .... close to 40 years ago, and plugged enough cards/cables together to last a lifetime. (I really don't like hardware stuff!). I've done basic Z80 and 6502 assembly up to ... web stuff today, and loads in between. I can passably describe the innards of some layer of various SQL engines, have compiled linux kernels and various packages from scratch, configured mail gateways, debugged DNS, setup/managed firewalls and intrusion detection systems, can often diagnose various application performance issues from description of symptoms alone, and can do many other things 'tech' related. (not trying to brag - loads of people here can likely do all of this, and more, and better, than me).
BUT... this set of skills often doesn't fit well within a traditional 'job' role. Finding situations where people can get/extract value from a wide variety of your skills is difficult (but can be rewarding when it's done).
I also can't do leetcode stuff, struggle with some 'point/click' things that others seem to find natural, and it can take me longer to 'produce' compared to others (although, I've often found myself cleaning up after others' projects when they leave).
I hope you have found (or can find) some situations that make the most of your skills, experience and perspectives!
Grinding leetcode is falling out of fashion anyway for many reasons, (but Leetcode will never tell you that), but it's still a skill to practice up on and be able to make it past an easy question without problem. It's not a skill you'll use normally at work, but the secret is no one's good at leetcode shit out of the door. It takes dedicated practice until you can pass it the interviews, just like any new skill.
If we’d all be stuck with the very basics, we’d be nowhere. This is why abstraction and specialisation are important.
We’re completely and utterly screwed without antibiotics and electricity and farmers.
And I’m convinced that at every step of our species’ advancement through abstraction and specialisation somebody warned of impending doom.
I don’t see how the same won’t apply to software.
> -Donald Knuth, 1974
In the fast-paced world of frontend dev, the last thing I want to do is revisit "complete" work, be it a lack of env parametrisation or something bigger. We make assumptions based on idiomatic implementation - failing to conform means work-items can slip ("This story will slip into the next sprint because the I had to convert the callback into an idiomatic action/reducer first").
I agree with you in general. But I do find that this litmus test sets up a moving target in some of today’s more trendy/culty language ecosystems.
With contractors it matters if they can code React fast today, not be up to speed in 6 weeks time
But they don't make money by knowing "how React works". They make money by "writing good-enough React code that pushes features to production". I think get you, and in some sense I feel identified with you, it's just that the industry has shifted from "let's care about our craft" to "let's write good-enough code to make more money"... makes me sad, but hey, it's business I suppose.
I couldn't care less that a candidate knows what "React hooks" are (that's probably gonna be outdated in 1 or 2 years). I care if they know how to write modular code. Management doesn't have the same opinion, though: employees usually work for 1 to 2 years at the same company... so knowing what "React hooks" are now, matters for them.
Being "good" has nothing to do with being a back-end programmer, imho. One could even argue that the front-end of today is far more complex than most back-ends!
That's a tough one. As I see it, a lot of the complexity in frontends is in framework feature bloat, subpar tooling and high tech churn as compared to backends. In a word: immaturity. Frontend doesn't guarantee backcompat like backend technologies do, which is also a large part of the (unnecessary) complexity. Obviously, frontends are additionally subject to the whims of fashion in a way that doesn't apply to backends.
In contrast, backends have mature frameworks that can deal with most concerns, allowing the developer to operate on a higher level and with greater confidence in the basic nuts and bolts. Package management is generally sane, to boot.
How much less complex would frontend be if we weren't trying to cram applications into a document model and instead had built-in support for controls/components, theming, data binding and inter-component events? If JavaScript didn't have so many shortcomings or perhaps even gradual typing?
In my experience, frontend skews young whereas backend skews older. That leads to junior class errors in frontends, such as not understanding the benefit of type annotations in a dynamic language and general cowboy behaviour. Perhaps the latter is also down to the general "move fast and break things" approach in JS land.
My own conclusion is backend developers as a group tend to be better, but that's mainly by virtue of having more experience under the belt, being less impatient and taking a longer view.
So I have complete respect for professional front end devs. They are every bit as smart as any other developer I’ve ever met.
And then with all that they make it look good too. Something I’m apparently genetically incapable of!
I think you're missing the point on every subject you touched on and I likely would not hire you either.
For one, most frontend developers now use environment variables to feed in configuration specific data, most notably URLs and feature flags, so that they don't need to do find/replace operations in the final scripts (most notably, minified bundles). It really has nothing to do with HTML, unless you've decided to interpolate values in static HTML pages. The environment variable concept is agnostic of any frontend framework and only requires a build tool of some sort, such as Webpack or Rollup.
On your point about not knowing React... I'm not really sure why you couldn't stick the landing here. If you knew they were a React shop, why not just look into it and build a React app on your own time? It's as simple as doing `npx create-react-app` (or something, I forget the syntax) and building your own React app. If you're such a seasoned frontend developer, surely this would be easy?
On the sad state of affairs: I really think this is another area where you're wrong too. I now know Knockout, Angular.js, Vue, React, and just now looking into Solid.js. I don't know the exact internals of each of these tools, but I can certainly explain to you what a digest cycle is in Angular and what hydration/rehydration means in React SSR. To someone who doesn't know the terminology, this can sound like jargon very easily.
On devops: a couple of years ago I found out about CI/CD, monitoring, and a couple of other concepts, and my workflow completely changed in both professional and personal projects. I now spin up entire infrastructures in AWS in minutes using Terraform. And frontend apps are now incredibly easy. I'm currently working on a Solid.js frontend application on my spare time.
So yeah... maybe you should change your attitude a bit. Based on what you wrote, it sounds like you might be the one that's not on the same wavelength.
You sound like the one who wants to hire a guy who already worked for 1-2 years in your department. These minor details at the interview like “in your whiteboarding session you didn’t name a constant like we usually do, wrong!”. Duck-diffing as it is it seems.
Otherwise you’re exerting yourself doing “normal” things. That’s not sustainable.
At the end of the day you are purchasing a COTS product specifically to gain efficiency of industry best practices already coded for you.
If you take a COTS product and then try to rewrite it to fit your "unique" business processes, we'll, that's why half of them fail.
Implementation of erp is incorrectly and disastrously viewed as an IT project. It is first and foremost a business transformation project. A company should be self-aware to say "HR|Accounting|whatever is NOT our core business or competitive advantage; it's not what we are great at. It's not a thing we should be unique in. It's a cost centre and we need to standardize and minimize that cost with help of people and software that were successful with many other companies".
(Source: I've been implementing Peoplesoft, a competing erp,for 20 years for dozens of companies, as a technical resource eventually wise enough to be aware it's fundamentally not a technical endeavour :-)
Rather than train everyone we hire to use horrifically bad and expensive barcode readers, we purchased cheap smart phones, put them in cases, and locked them down to run an app that uses the camera to scan barcodes. Drop a phone? It’s encased in rubber. Run it over with a forklift? Toss them another one from the box and then figure out why this only happens on Tuesday afternoons.
We already need a dev team for other reasons. Adding another decent programmer to create and support internal apps isn’t that expensive in the long run. Plenty of good devs like me who are happy to work remote from the Midwest at less than FAANG rates. :)
This is the best approach. Inventory is a great example of something that is both very important to an ERP and needs to be modeled impeccably if you want accurate costs (think license plate numbers tracked back to manufacturing), but at the same time you sure as hell don't want your ERP to be the "system of record" for operational systems.
It was a very humbling experience working with accounting and finance to close the books and update forecasts.
The part you're not going to like hearing is that, due to laws/regulations, that "default world view" may be the best way to approach that problem for that given module/area (e.g. how to structure benefits or compensation). "Creativity" in the ERP space is costly.
Also reducing your variation to something that's configurable as opposed to custom codebase means you don't have to do extensive testing whenever a patch or upgrade to the ERP software comes out.
You could customize it to match your business, but 90% of the time that would cost more than reorganizing your business.
Either you match your business to the SAP Way or your multi-million SAP integration project will fail. There are no other options.
You can theoretically prolong the inevitable by modifying SAP to fit your business model, but then it'll just break and fail during the next update.
Even better if the tools are selected based on previous experience alone.
You Can't Buy Someone Else Caring about Your Problems
It seems like you can hire experts to understand and consultants to care about your problems, but someone has to bring the intent and to close the loop.
But prolonged exposition and mutual relationships (even ones kickstarted by selfish, careless objectives such as "Pay me!" or "Go to war for me!") necessarily lead to intertwining of identities. And once you consider something (or someone) a part / extension of yourself, caring follows.
In other words, given enough time and substantial interaction, the lines between "you" and "me" blur. That's just a biological (physical?) observation; cf. parasites and symbionts, nation building, product marketing, leadership…
Of course it's a scale, not a binary care / don't care. A doctor may care very little about a celebrity he knows he'll be interacting with for a year or two, max. But family doctors still exist, too.
IMO it's down to arguing semantics about how "tight" is the causal chain between the cause and effect.
Do you perceive the cause (repeat buying) and its inevitable effect (caring) as sufficiently distinct in time and space? Then I guess you didn't buy the caring, you "built it through repeated interactions".
I personally see that boundary as mostly linguistic, and tend to not draw the distinction.
This is easy: when you give people a huge amount of money to care about your problem, they will. This, of course, does not imply that they will be able to solve them.
> You Can't Buy Understanding of Your Problems
This is less easy, but also possible: spend sufficient money so that highly intelligent people (think graduated mathematicians or theoretical physicists) will organize their life around understanding your problem. Because they are highly smart, they will very likely understand after some amount of time (hey, understanding highly complicated stuff by reading papers is what you do in graduate school).
---
So the problem rather is: you are not willing to spend that much money or are far too impatient on people (i.e. you want a "fast solution" instead of someone who really deeply wants to understand everything from ground up as you do when in math research).
You can pay them enough to care as far as they get their last payment. How do you get them to care what happens after that?
Or you can share it by having partners or shareholders.
If I am at an organization and not directly on a software development team and want to do a simple data transformation between two systems, how would I go about getting an environment to run my process? Even if I know how to write it using a general purpose language there are probably too many steps to go through to get a server environment to run my code on. With a low code solution, I can get my simple process running and automated much easier.
A little while ago there was an article about the python environment run at big banks that allow banking analysts to easily use python to solve their day to day problems. The banking python system was built to allow these people to quickly write python without much organizational overhead and therefore saw wide spread adoption among non traditional software developers.
I have been thinking about this space because I am trying to build a platform on top of serverless (FaaS) platforms that would make it easy for companies to empower workers to use general purpose programming languages to solve their business problems.
This problem was solved in 80ies on most timeshare platforms(read unix) where you would simply let users access an general purpose environment on a shared server and run processes in the background or kick up batch job using some kind of scheduler(crontab).
The old unix "shell account" should really be the benchmark for FaaS to beat and so far i dont think anyone have gotten close for small scale project.
My experience is that my first cgi-bin script were about a order of magnitude easier to deploy that anything other then say a traditional php/mysql script. and i had the flexibility to use basically any programming language back then too.
I did not have to learn git, figure out how the cloud router used worked, i just had to place a file in a directory. For crontab it was the same dump the script to a directory edit the crontab file and it worked and it was the same no matter who i bought the service from.
Sure there were scalability issues, and the security was questionable but in terms of ease of use are we really moving forward?
https://docs.microsoft.com/en-us/azure/azure-functions/funct...
Here is video tutorial
https://www.youtube.com/watch?v=1A7vp3zAB9U
Or in the context of low code tools, Azure Logic Apps
https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps...
And the code itself did not contain 10 lines of vendor specific scaffolding to run either but were straigt onto the business logic.
Where is the platform where i can take an completely standardized scriptfile use my preffered ftp/scp client and upload it into an runtime configured to run inside of the corporate firewall?
So if you want that approach then, IT would set an "static HTML web app" instance for "~/public_html" version, which you can then ssh into.
https://docs.microsoft.com/en-us/azure/app-service/configure...
or have a VSCode like experience editing directly your site files,
https://social.technet.microsoft.com/wiki/contents/articles/...
So, IT sets the server up once and maintains it and provisions and deprovisions accounts, but everything else is self service. There's no need for IT to be involved when somebody wants to "launch a new web page". It was a pretty nice system for what it was.
Besides given the near constant issues we see around misconfigured s3 bucket i am not sure the average cloud function meets security standard anyway.
Yep. And particularly the fundamental issue of so-called "general purpose" programming languages:
They are *not*, in fact, general purpose.
Which in turn leads to the problems described in the article, because it's all far too domain specific.
The answer, IMHO, is to make languages that actually are general purpose and not just algorithm-DSLs. That can handle integration without being integration-DSLs.
My stab at this is http://objective.st/
https://docs.mulesoft.com/dataweave/2.4/dataweave-cookbook-e...
I wonder if in the near future we'll see a similar article regarding security - "You Can't Buy Security".
* Step Functions module in the AWS CDK: https://docs.aws.amazon.com/cdk/api/latest/docs/aws-stepfunc...
* Step Functions Data Science SDK (python): https://aws-step-functions-data-science-sdk.readthedocs.io/e...
There is first class support for defining Step Functions using real programming languages (although it does compile down to the states language dls before deployment)
Seems like all the same concerns from the article apply.
An infrastructure engineer's top motivation does not have to experience a deep appreciation of the faux philosophy in your founder's ghostwritten business tales book for him/her to be an effective employee. Things like soft skills and technical know-how are a lot more important - things that cannot be easily faked in an interview situation.
The best interviews are those that do not follow a script. Remember: In a job interview, the potential hire is not the only one on trial.
What companies are paying me for is to focus on and solve the company’s specific problems.
I would think visual systems might be in a better spot to visualize change over time. Some of Tufte's diagrams have interesting ideas of how this could be represented statically, but turning static code diffs into illustrated animations might even be better than code diffing...
I would love to read more on this particular topic but from the point of view of someone who needed to get the job done and tried no/low code tools and building his own thing and learned the pros and cons of each approach. Everything else looks like salespeople talking.
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.
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.
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.
By this definition, Excel is a form of integration tool. A spreadsheet doesn't "directly solve a business problem". It's basically just a piece of paper with lines on it, along with some "programming formulas". A hammer would be an integration tool if it were digital.
The technology industry is wholeheartedly committed to selling you the idea that you need to write software. The industry knows that will guarantee new customers (and profits) for decades to come, for all the things you'll need to buy into to "solve" the software engineering problems you'll undoubtedly encounter. But do you need to write software to solve it? Most other industries do not make things themselves when they need to solve a problem. They don't buy anvils when they need nails, they don't buy sewing machines when they need to clothe their workers, and they don't build industrial machines when they need to produce factory goods. They don't build cars when they need to deliver pizzas, nor build ovens to bake them, nor knives to cut them. There are always exceptions, but for rare, exceptional cases.
I think the meat of this article is predicated on the idea that it's expected that you need to be somehow developing software to solve business problems. But really, none of the technologies in this article should be needed to solve most business problems. If there isn't an existing product for sale that's general enough to solve your problem, that's the problem we should be solving; not writing software for every single business case under the sun.
> By this definition, Excel is a form of integration tool. A spreadsheet doesn't "directly solve a business problem". It's basically just a piece of paper with lines on it, along with some "programming formulas". A hammer would be an integration tool if it were digital.
You're misreading that quote. The direction is actually important in conveying meaning, it's like trying to misread "Every ancient poet known as Homer was a man" as "all men are ancient poets known as Homer".
If you’re unlucky it’s your only integration tool. When there are no APIs, when you can’t get approval to use a tool or language, when the DBAs won’t return your calls; then export to Excel is the only integration tool you’ve got.
A few years back I remember a big corp explicitly telling me that a project for an Excel based integration between some systems would have easily got buyin and budget. Despite it being in a broader sense a crappy tool for the job due to everyone having excel installed and almost nobody being able to get approval in a reasonable amount of time for anything else to get installed it did appear to be the easiest option in the circumstances. Before this I think I was one of those people who just ruled out using Excel for integrations because I just couldn't see how it could possibly be the best option in any circumstances.
All of this was tied by our homegrown queue software.
Some years later, I was tasked with migrating HP-UX to Linux, in stages, and I was lucky enough to have found all the queueing source code, and I rebuilt it, imperfectly, on Linux. We hired back our past workers, including the original author, who made perfect my original port.
As the years have passed, I continued to improve this code, compiling with directives from "hardening-check" after bug hunts.
It has tied me to my role, but I suppose that I am happy here.
In the meantime, the business integration tools can learn more concepts from general programming languages, like: version control, unit test, external variables, integrate sub-components into another combined component, shared macros, etc.
[0]: https://en.wikipedia.org/wiki/Microsoft_BizTalk_Server [1]: https://partner.microsoft.com/en-us/solutions/microsoft-bizt...
BizTalk heyday was during the Visual Studio.NET early days when SOAP was going to take the up the world of distributed computing as main replacement for CORBA/DCOM.
So true !