11–20 of 143 posts
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. He is a software life coach.
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. He is a software life coach.
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…
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. 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.
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.
Otherwise you’re exerting yourself doing “normal” things. That’s not sustainable.
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. He is a software life coach.
Not sure why you are writing this. Fowler isn't the author of the article. martinfowler.com nowadays is just the Thoughtworks blog. I can't remember the last time reading a article by Fowler on there.
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 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...
Earlier quoted context omitted.
Not sure why you are writing this. Fowler isn't the author of the article. martinfowler.com nowadays is just the Thoughtworks blog. I can't remember the last time reading a article by Fowler on there.
Even better, we're listening to someone who has accomplished less than Martin Fowler.
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.