81–90 of 142 posts
Fowler states: I’ve long known that when you’re doing very creative work, such as writing or programming, the useful hours you can do in a day is rather less than the accepted industrial eight. I don't want to disagree with him as this is quite subjective, but when I am totally engrossed in solving a problem, I get into a flow and the time flies by. If the problem is both interesting and challenging, I can't wait to…
Probably not necessarily on topic - but I really want to say that this guy has been the #1 source of pain in my developer career so far. There've been so many projects where I had to implement some solution some way because the "architect" said "that's how Fowler recommends it, so that's how we're doing it", even if the solution was so bad that everyone saw it coming back to bite us from miles away. I read his books…
Everybody reads Fowler and does horrible things thereafter for a while. Hopefully, you come out of that phase and learn what is worth bothering with and what is not, without too many years and without too many scars and too many failed projects. Some never do though... The phase of my career where I drank the SOLID kool-aid and studied and tried to apply the hip architectural patterns is one of the darkest and most r…
> The phase of my career where I drank the SOLID kool-aid and studied and tried to apply the hip architectural patterns is one of the darkest and most regrettable. I'm still dealing with bad decisions made in code bases from that period.
or maybe something else?
(i have my own experiences, but im really keen to hear from others)
I like The Agile Manifesto . I feel that the jury is still out, on how effective it is, in practice; not because it's bad, but because I think it has problems in application, in the regular schlub world. Note that I like the Manifesto, but have been underwhelmed by what I've seen, in its expression. I feel that Mr. Fowler, and his compatriots came out with a great "vision statement," that may not be applied particula…
This resonates a lot, I like this idea of a "shepherding process" and digger deeper into what it takes to make big projects successful over time. That said, I think distilling down this hard-won experience tends to lead to cargo-culting. Just look at "Agile" itself and how it's been embraced and then twisted by consultants into the exact opposite of what was intended by The Agile Manifesto to begin with. This stuff s…
That's the rub. I feel as if it works extremely well, in my own work, but I currently work mostly alone (I am part of a loosely-coupled team, but I completely "own" my own part of the project).
Getting it to work for a team, is not so easy.
Organizations run on Process (note the capital "P"). I feel as if true Agile is something that we need to personally inculcate into our own lives, as Practice, Habit and Understanding. We need to be constantly working within our methodology, which, in my case, is equal parts Habit, and Experience. I don't think it's something that can be taught. It needs to be learned. The reason that I separate these two words that seem to mean the same thing, is that "teaching," is an outward-facing practice, while "learning" is an inward-facing one. I feel that we must -each and every one of us- make the effort to learn how to code as a craft. It starts within each of us, and that's not something that can be foisted upon anyone, or dictated with process. We also need to completely understand our craft, and the work we do. It should not be simple rote. Habit and rote are two different things.
There's no "buzzwordy" or consultant-ready answer to that.
TL;DR: It's complicated.
Probably not necessarily on topic - but I really want to say that this guy has been the #1 source of pain in my developer career so far. There've been so many projects where I had to implement some solution some way because the "architect" said "that's how Fowler recommends it, so that's how we're doing it", even if the solution was so bad that everyone saw it coming back to bite us from miles away. I read his books…
https://martinfowler.com/bliki/MonolithFirst.html
Fowler shares ideas of architecture, but in a nuanced way, and clearly states when it might be appropriate, and what are the costs and complexities involved.
The problem in your case seems to be more of "Architecture Astronauts".
https://www.joelonsoftware.com/2001/04/21/dont-let-architect...
I wouldn't be surprised if the mere existence of a software architect title incentivizes overly complicated architectures
Probably not necessarily on topic - but I really want to say that this guy has been the #1 source of pain in my developer career so far. There've been so many projects where I had to implement some solution some way because the "architect" said "that's how Fowler recommends it, so that's how we're doing it", even if the solution was so bad that everyone saw it coming back to bite us from miles away. I read his books…
Somewhat flippant, but also a serious question - do people like Martin Fowler and uncle bob actually do anything or do they just describe systems that do not (and probably will never) actually exist? Have they built real world software, or do they just describe some ideal state that has never actually occurred in reality - some kind of geek porn? I’d much rather listen to people who have actually done things than peo…
Earlier quoted context omitted.
By failed, I think they mean “spectacularly wide usage, with some drawbacks”.
REST as Fowler advocated for is used approximately nowhere. The widely used thing known as REST is very unlike it.
Earlier quoted context omitted.
> explain why REST has failed so spectacularly in the JSON API world Could you elaborate on this?
By failed, I think they mean “spectacularly wide usage, with some drawbacks”.
There are very few JSON-based hypermedia APIs being built and the few that were are almost never used as a uniform interface. They are treated as a normal, RTFM API.
In REST-ful terms (real REST, not the "REST is JSON with hierarchical end points, kinda" sense), REST has failed spectacularly in the JSON world.