Live data from Hacker News

You Can't Buy Integration

martinfowler.com

21–30 of 143 posts

Re: You Can't Buy Integration

#21
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.

Re: You Can't Buy Integration

#22
post #4

You Can't Buy Understanding of Your Problems 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.

Hah, I posit that there is a _very_ low possibility of buying someone to care about your problems.

This is why visiting a doctor can be a rather frustrating experience.

Re: You Can't Buy Integration

#23
post #7

Really great read. Long but worth it. 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". Mean…

There's an even worse shortage of qualified interviewers out there.

Re: You Can't Buy Integration

#24
"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.

Re: You Can't Buy Integration

#25
post #7

Really great read. Long but worth it. 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". Mean…

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.

Re: You Can't Buy Integration

#26

Earlier quoted context omitted.

Hah, I posit that there is a _very_ low possibility of buying someone to care about your problems.

This is why visiting a doctor can be a rather frustrating experience.

Exactly right! The doctor has her own problems to care about!

Re: You Can't Buy Integration

#27
post #7

Earlier quoted context omitted.

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". Mean…

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 byteco…

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.

Re: You Can't Buy Integration

#28
post #7

Really great read. Long but worth it. 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". Mean…

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").

Re: You Can't Buy Integration

#29

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 howev…

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.

Re: You Can't Buy Integration

#30
post #4

You Can't Buy Understanding of Your Problems 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.

Hah, I posit that there is a _very_ low possibility of buying someone to care about your problems.

Everyone has a price.
Post reply on HN