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.
I got bounced off a front-end job once, for not being good enough at React.
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!"
I have been in a similar boat. I was spending a bunch of time avoiding extra API calls and extra renders in React and the team I was working with didn't seem to understand that there were potential performance issues around that. They said "just use memo"
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.
It does make you wonder what is going to get missed though, doesn't it? Each generation gets to work on a level of abstraction higher than the one before it.
I think about that often when I think about all the things I don't understand about hardware and EE.
I did computer engineering in school 20 years ago, and have always enjoyed understanding technology. So I know what is happening from the gate in the cpu all the way up to the pixel in the monitor. The downside is that I'm spread pretty thin. I can't pass leetcode exams in the 30 minutes of allotted time, ops people can't understand why I don't use containers, and my knowledge is probably useless in making a modern CPU.
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.
Custom software won't be dead because you can't buy integration off the shelf. And JIRA specialists and similar roles will just eat up more of the potential workforce that could be employed as software developers, so software developers will stay a valuable scarce resource.
At some point, you may have to look beyond traditional employment situations to best make use of your technical knowledge and experience. However, it might mean moving to consulting and possibly 'selling' yourself on a more regular/periodic basis.
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!
I found that I make the most money investing, mainly via Tesla over the past 8 years. I only have about 1% of the engineering skills and work ethic of Elon, but that has been enough to understand what he is doing and ignore all the people on CNBC with MBAs who don't understand engineering.
There are still places that need and are looking for that sort of help! Especially inside smaller cloud companies (Digital Ocean, Linode, etc) (or any company that's got their own datacenters, eg Facebook) where the solution to a problem can't be to use some AWS service. A heavy hitting sysadmin (embrace calling it devops instead) like yourself is necessary to getting stuff off the ground to a proof of concept stage, then to production.
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.
I think there are quite a few people like us - I have a different background from you, but I do feel like I'm spread a bit thin and haven't really specialized in anything. The good news for us is that I think it's not the end of the world - it's still possible to deep dive into something and specialize in it, so long as you can find the time :)
As another generalist that enjoys occasional (very) deep dives but never gets tied down to one platform/tool/skill/problem set - being a good jack of all trades is it's own special skill, and it is quite rare.
Small and medium sized teams really need this sort of person as the mythical "10x" engineer, and in many cases this is a great stepping stone to technical/team leadership, PM roles, and entrepreneurship.
This is a nice glass-half-full way to look at it, which honestly I hadn't considered doing before. I will try to think about things this way a bit more :)
Thing is, if you needed to make a fire in the rain and skin & prep and animal, you'd have a good chance of at least getting most of the way there as you understand the concepts. The problem here is more equivalent to not even knowing what and animal or fire is, nevermind how to do the tasks at hand.
> "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.
I've worked with people of varying skill-levels but personally gravitate towards those who can code idiomatically. For me it's important I write idiomatic code and follow the language/framework/api guidelines to the letter so I don't become a maintenance burden to my team.
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").
Which idioms? This week’s? Or last week’s? If I’m at guru level and am capable of evolving to whatever next week’s idiom is, can we code together then?
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.
I think it depends: not using specifically env variables for configuration should let be a big deal. But hard coding values rather than using some sort of configuration file is bad practice and could cause issues on a team.
This is fair, but silly then to interview someone who “doesn’t know React” if you’re not willing to teach the framework. Frameworks and languages are easy to learn, idioms and all. If a candidate is knowledgeable and can write idiomatic Vue or something similar, why would you think they won’t be able to do the same with React?
> 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".
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.
I don't think React hooks will be outdated in 1-2 years. Between Svelte and Vue I don't see a path for a formidable challenger. You get the complete ecosystem around it. There's tools like Stencil, and I like those tools, but giving people whole-cloth access to make anything, with no 'base' design system, tends to lead to the creation of inaccessible UIs. And it's quite simple to introduce a11y issues. The front end stack isn't moving at the speed it did in the early 2010's, of which I am personally appreciative of.
I agree. I think the next big shift will be a fairly big one, not an incremental step.
Personally, my money is on Phoenix LiveView - the syntax and concepts aren't super familiar, but the benefits of no longer having to build a lot of your logic multiple times and the ease of scaling this platform are extremely attractive.
I would like to hire you on my next web aka "phony react mobile" project. And Im not kidding if I had your deets I would totally hire you.
This is sort of the exact problem but we cant talk about the exact problem.
if you are that good, then why are you wasting your time with front ends? Go into databases. You're apparently already starting to age out of the young and dumb and works overtime flotsam.
I work at pretty much all levels of the pie, but my passion is with what the user interacts with, which is why I tend to gravitate towards the front-end.
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!
> Being "good" has nothing to do with being a back-end programmer, imho
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.
I’m a mostly backend dev (I dabble in Vue), but it’s seemed to me for some time that browsers are effectively operating systems. The level of complexity of the JS/HTML/CSS troika is staggering, and the number of APIs in a browser pretty much gives you access to abstractions of the whole machine. It’s nuts!
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.
I agree with grand parent regarding .env variables. During an interview it shouldn't matter whether a candidate uses a .env file or a shared config javascript object, just as long as the candidate can demonstrate the ability to write maintainable code, and isn't excessively dogmatic about their preferences.
Why would one go and s/// in a minified bundle when you have the code? I don’t get it. Is your code read-only? Write-only? You can’t follow imports, can’t lookup a symbol definition?
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.
I’ve hear the way to succeed with SAP is to reorganize your business to match either the default world view or some other cookie cutter variant. Essentially using it no code style.
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 :-)
This is why my company has custom applications that talk to the ERP for certain departments. Inventory control in the ERP isn’t going to work with reality. The data modeling is good enough but the interface is not.
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 why my company has custom applications that talk to the ERP for certain departments.
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.
My wife worked for an association that got bit badly by the one true platform bug. They had an excellent publishing platform, with features that were then incompletely implemented in whatever association-management platform it was. I couldn't imagine why a clean, limited interface to the platform couldn't have been implemented at less cost. She was fortunate to be gone before the change was implemented.
Yup there's a few approaches. These days most ERPs have nice semi-modern interfaces making mix-and-match easier, but honestly over 20 years I've seen industry go through 3-4 long cycles between preferences for single-vendor/stack homogenous solution, or "best of breed" mix (I know, buzzwords all but sometimes handy:). It seems one of those things that goes and comes around....
This outlook is actually endemic in the ERP implementation space.
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.
One of my biggest customers was bought by their competitor after a big SAP implementation. The consensus amongst management was that the project weakened them so much they became vulnerable to takeover.
Twenty-odd years ago we sat through presentations by Peoplesoft implementation consultants. When I looked through my notes, I found that all of them said, with slight variations in the wording, "you have to do it Peoplesoft's way." I'm sure they were right.
I have it seen time and again. Organizations and leadership being faced with a problem and jumping directly to tool / software selection and implementation before really having understood the problem itself, the processes and requirements. After selection, directly to implementation. Because, you know, we a re agile and working in sprints. So we can sort out architecture and interfaces as we go. End result, tools force you into the use not understood processes that have nothing to do with your business requirements whatsoever, an architecture that is cobbled together and users that don't understand neither.
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.
I posit that paying money only buys the appearance of caring, not the actual caring. That is the reason celebrities get (got? Not up to date) doctors who prescribed addictive drugs, because they just gave the client what they wanted, not what they needed. You really want someone who speaks truth to power, not just pleasing nonsense. And the power must be able to discern the two.
This is true prima facie, as a snapshot of "caring".
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.
Very good points, I agree with the gist of your post, I just want to say, that, still you're not really buying it, but building it, through repeated interactions.
Yes, but you can buy repeated interactions. What's the actual difference then?
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.
You can hire experts to pretend they care and do whatever's the most convenient for them and since you don't understand, you'll never know the difference.
> You Can't Buy Someone Else Caring about Your Problems
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).
Yup, somehow you need to get people to own your problems for you or at least attention on your problems. You can rent it by paying people (wages). You can sell it by making it seem important to them (Tesla has no marketing department or budget for instance).
Or you can share it by having partners or shareholders.
Fowler doesn't ship. When you read his articles, especially when they make you feel like you know something others (especially those awful management types) don't, remember that he hasn't made anything.
Fowler isn't the author so if you're reading this article you aren't reading one of his (Fowler's) articles. Check the byline: Brandon Byars. I have no knowledge of this person so can't comment on his particular relevance, but seriously, took 1 second to see who the author is.
Please don't do personal attacks on HN. The damage to the ecosystem outweighs any benefit such harshness provides. You can make your substantive points without that.
It is a weird article. Fowler obviously knows a lot about integration, but since his business is about writing software he tries to discredit "low code tools", so that more people use his services. I think that those tools are great for exactly the reasons indirectly stated in the article - they take the mind off the implementation and let you focus on bigger picture. I was involved in tons of integration project and they were always 90+% about communication: agreeing on interfaces. The actual implementation is almost always trivial, with tools like TIBCO or MuleSoft you can sometimes do it in 15-30 minutes (for simple flows, the more complex ones can take up to 3 days).
The post isn't bad or anything, its just that coming from Fowler (or a partner) who sells software services and books on software for a living, it is as biased as it gets.
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.
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 en...
Regarding visual diffing: "The delta between source code commits can only be represented textually; graphical palettes are not designed to represent change over time."
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...
Business logic happens line by line between interfaces. Coding may be all ifs and for loops, but when it comes to implementing a new feature, having chosen carefully where to draw the line between, say, your model and your view can be the difference between a 10 line patch and a complete rewrite.
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 line “coding is just if statements” really annoys me. I used to think this earlier in my career. It’s technically true but it means that you haven’t really grasped what makes programming hard.
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.
Coding is just if statements, more or less. Programming and coding are different words with different meanings, though. What is the reason to conflate them?
Since this is HN, and pedantic corrections are popular, I feel the need to point out that "coding" is the original term. I've seen very old references where creating instructions for a machine to execute was referring to "coding". We're talking Jacquard Mills or Babbage machines here.
That is not true, though. Coding is about writing code, whereas programming is the thought process that goes into writing code. The original comment establishes the same distinction, so it is not exactly a novel separation. The question was why then conflate them when they were already recognized as being different?
> Java is particularly unforgiving for code where ones thoughts are unclear.
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.
Kotlin has been a godsend when it comes to breaking free of Java dogmatic thinking. The effort to write good functional code is so much less. That's not to say that classes are useless. I try to limit class usage to data structures that do no more than:
- 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
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)
Agreed. Exception here is when you're making the trade-offs to buy into a DI framework--which you could argue is a descendent need from the "everything is a class" worldview. Pure/dependency-free util functions can very naturally live outside of all of this. But, the minute you have functions that depend on inherently stateful infrastructure (e.g. datasource connections--so, most applications), then those functions become inherently stateful--which makes them less natural to exist as pure utils and starts to make DI more attractive--which leads us back to placing pipeline code within classes. Alternatively, you could expose only the stateful pipeline code within singletons, but at some point you start to fight the community patterns--which means you start to lose out on community goodies. To be clear, this is all only based my experiences and I'm not dogmatic at all about any of this. Times change/everything-old-is-new-again. I'm sure classes will make a comeback, and then go out of favor again--as is life.
I think you are confusing Java and the tools built on top of Java.
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.
"Integration software products ... are not products that directly solve a business problem. ... They are programming languages, bundled with a toolchain and a runtime to support the compilation process."
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.
> "Integration software products ... are not products that directly solve a business problem. ... They are programming languages, bundled with a toolchain and a runtime to support the compilation process."
> 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".
> By this definition, Excel is a form of integration tool.
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.
I think a lot of skilled software developers might be unaware of just how bad the practices can be in non-software companies regarding software development.
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.
In Microsoft BizTalk one could make transformation rules not by drag-and-dropping but by coding in some weird XSLT dialect. It was a joy to use compared to the usual three-pane screen.
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.
I agree with most the tradeoffs that were brought up with "low code" integrations tools, but I feel like none of the tradeoffs of using a general purpose program language were discussed. My viewpoint is that most organizations reach for these solutions because they provide highly available runtimes that people can quickly access.
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.
It's the configuration complexity clock all over again. Code errors cause outages, then we impose a bunch of process and restrictions on code deployment, then we make our code configurable so that business users can easily change the behaviour, then configuration errors cause outages.
How do you get time/instances on an no code platform?
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?
Since you gave a cgi-bin script as example, assuming you have an Azure Cloud account, you can easily do it via , provided it is written in JavaScript, PowerShell, TypeScript, or C# Script.
And this is the equivalent for cgi-bin "vi ~/public_html/cgi-bin/hello.sh"
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?
You are missing having IT set up a UNIX server instance, with Apache or NGINX on it, configure firewall, public IP DNS entry, and then having the rights to ftp/scp into it before being able to call vi into hello.sh.
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.
I feel like you must know this, but the convention back in the day was a UNIX server for an organization, that would handle essential tasks like email, that everyone could log in to and have access to common UNIX tools, and that would automatically serve "/home/$USER/public_html" as static HTML web apps under example.com/~$USER.
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.
> none of the tradeoffs of using a general purpose program language were discussed.
Yep. And particularly the fundamental issue of so-called "general purpose" programming languages:
They are *not*, in fact, general purpose.
What we call general purpose languages are, in fact, DSLs for the domain of algorithms. See ALGOL, the ALGOrithmic Language. But we think they are general purpose, because that's what we use, lacking other options. And this mistaken categorisation leads us to the incorrect conclusion that things that aren't handled well by these "GPLs" must therefore be handled by DSLs. Or Domain Specific Tooling.
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.
Ok so here's the deal, although this is sort of well written-ish.
There is absolutely no surprise waiting for us in COTS, phony 4GLs that purport to "solve a problem".
I mean really? The fact that people still huck these tools means the software business might not be dead. Now if you work for a company that buys these things, I hope your not in tech. Because these fool things which are "container engines for consultants", will cost you a ton of money.
Maybe you prefer it that way?, its your money. The technical argument which sort of tried to make some point relative to event driven architecture was pretty obviously weak. Whether or not I personally agree with that architecture, I think that there could be arguments made there.
But we have MUCH bigger problems in tech. Some of them we cant talk about openly.
Like labor sourcing and scrum. So we may have people problems folks.
Let tool salesmen do their jobs and tend your own field and your own flock.
It's not really clear if this advice is for within the enterprise (a company that maintains so many systems they spend millions to integrate them) or at the edge (a company that needs to integrate with multiple third parties). I can see the argument for the intra-enterprise work being valuable, but at the edge I'm less convinced.
I arrived in my position in the late 90's, greeted by HP-UX, VAX VMS, and Unisys OS2200.
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.
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 is first class support for defining Step Functions using real programming languages (although it does compile down to the states language dls before deployment)
Yes, Best programmers can win against any integration tools. But in real world, it rare to find enough "good programmers", so they can not abstract good components and good layers. So, at this case, the business integration tools will win. Those tools mainly sell best practices and well-tested components, so, although you are limited to what those tools provided, but will solve those tricky small things without your worry.
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.
There's a lot of things you can't buy in IT. There's a lot of things you don't need to either because they are free. For all this you must find people who are passionate and have interests aligned to your own. This is how I aim to hold the interviews I conduct for infrastructure engineers. The most important question I ask is "Why do you want to work in this position?". 10 years ago I used to care mostly about candidate know-how, now I care mostly about drive.
That particular question is a major red flag to me as an interviewee, maybe because most people who ask it are not interested in an honest answer (the most honest being: "you offer money for work, I offer work for money"), but have been told by some HR voodoo master that this almost-ritual incantation reveals deep psychological insights into the interviewee's mind. At best, it only tells you if they prepared by memorizing ideal answers and can lie convincingly.
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.
That particular question springs from my own motivation at fulfilling that role. I do not know why you think I copied it from some faux book. And "you offer money for work, I offer work for money" is not a valid response in some cases, some positions require high internal motivation. This is all from my experience of hiring people to work under me, I don't care about the company or HR or anything like that. I care if I will have to push them constantly to deliver or if they desire this for themselves.
What are peoples’ thoughts on industry data models? These feel like integration by a different name. They often come with integration tooling as well as the core logical/physical model. That tooling is often “config not code”. And the database(s) which instantiate that data model act as the integration nexus for an organization, like a passive ESB. They become the architectural center of the organization, and the primary concern is conformance to the model (with the aim of achieving some future reusability benefit) rather than creating clean interfaces over capabilities.
Seems like all the same concerns from the article apply.
Pretty much the same as my opinion on the topic. The nature of integrations is that you must expect anything. I worked with some of these flow engines and sooner or later you end up writing small integrations that are used by the integration tool. In many cases it would have been easier to just have everything in one integration code base. At least for debugging.
I have worked with Mulesoft before. It is a classic case of over-promise and underdeliver. It promises drag and drop functionality to integrate systems using its Mulesoft Composer. While that may work for many situations, often I wound using Anypoint Studio (eclipse shell), struggle with its dataweave data manipulation language, and googling the java error messages it spat out. It is also expensive as all Salesforce products are. With Mulesoft's Cloudhub, we pay for "virtual cores". We schedule Mule package to the tenth of a virtual core and stack their schedules to not exceed our assigned limits. Each virtual core is essentially a virtual machine/java process/network that is independently restartable. My biggest complaint is dataweave. It mixes objects/arrays/literals without aiding the developer in any meaningful way.
142 comments
[ 3.2 ms ] story [ 206 ms ] threadI wonder if in the near future we'll see a similar article regarding security - "You Can't Buy Security".
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.
I would like to hire you on my next web aka "phony react mobile" project. And Im not kidding if I had your deets I would totally hire you. This is sort of the exact problem but we cant talk about the exact problem.
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.
He is a software life coach.
martinfowler.com nowadays is just the Thoughtworks blog. I can't remember the last time reading a article by Fowler on there.
https://news.ycombinator.com/newsguidelines.html
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 en...
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...
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.
- http://www.geeksworld.org/strip_982.html
- http://www.geeksworld.org/strip_984.html
https://pbs.twimg.com/media/FFue_fIVUAMrSu1?format=jpg&name=...
https://twitter.com/nice_byte/status/1466940940229046273
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.
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.
[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.
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:
What we call general purpose languages are, in fact, DSLs for the domain of algorithms. See ALGOL, the ALGOrithmic Language. But we think they are general purpose, because that's what we use, lacking other options. And this mistaken categorisation leads us to the incorrect conclusion that things that aren't handled well by these "GPLs" must therefore be handled by DSLs. Or Domain Specific Tooling.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/
There is absolutely no surprise waiting for us in COTS, phony 4GLs that purport to "solve a problem". I mean really? The fact that people still huck these tools means the software business might not be dead. Now if you work for a company that buys these things, I hope your not in tech. Because these fool things which are "container engines for consultants", will cost you a ton of money.
Maybe you prefer it that way?, its your money. The technical argument which sort of tried to make some point relative to event driven architecture was pretty obviously weak. Whether or not I personally agree with that architecture, I think that there could be arguments made there.
But we have MUCH bigger problems in tech. Some of them we cant talk about openly. Like labor sourcing and scrum. So we may have people problems folks.
Let tool salesmen do their jobs and tend your own field and your own flock.
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.
* 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)
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.
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.
Seems like all the same concerns from the article apply.
So true !
https://docs.mulesoft.com/dataweave/2.4/dataweave-cookbook-e...