I write UI apps, using Apple's UIKit. I can generally write a fully functional app, in a day (or less). I do it all the time, for test harnesses. I spend more time on apps that I'll actually be shipping (mostly doing stuff like aligning UI elements and applying accessibility and localization, which can take quite some time. Lots of iteration).
I'm putting the finishing touches on my second app in about a month and a half. It's a "total rewrite" app; just like the previous one (which is already out there, and has had over a thousand downloads already).
I did these apps alone. After this one is out the door, I'll return to the app I've been working on for a year and a half. These were just "side trips," because I was getting burned out.
UIKit was designed as an MVC framework. If you use a different pattern, then "you're holding it wrong." You are using the framework in a manner for which it was not designed.
That is not always bad. I can't actually think of any examples, right now, but I'm sure that some of the new methodologies are more effective.
I strongly suspect that some of the new development patterns (I won't name them, because holy wars) were developed specifically to break up projects that are really best done by one or two skilled engineers, into ones done by a fairly large team of relatively unskilled engineers.
Might work out. I don't know. That's not how I work. YMMV.
really best done by one or two skilled engineers, into ones done by a fairly large team of relatively unskilled engineers.
I think this is mostly a way to flatter ourselves about things we don't like. It's perfectly fine to not like things but as an argument, it is pretty poor. It's at also at the core of PG's 'blub language' thing, a mistake at the time that's aged even less well.
I'm sorry. It must be my age, but I don't really understand the comment. Was I supposed to be insulted? It may have fallen wide of the mark, if so.
I wasn't railing against anything that "I don't like." I was simply stating that I use MVC, on a regular, daily basis, and it gives me the results that I require.
And, I know, for a fact, that some of these patterns are used for exactly the reason that I stated. I know this, because I have talked to the managers that decided to use them, and that was the motivation. I don't even have an opinion on whether or not that is bad. Many of these teams do great work.
Maybe things are better, done in ways beyond my limited, saurian, comprehension.
All I can say, is that I'm able to churn out a lot of stuff, of extremely high Quality, in a remarkably short time, using these prehistoric patterns. I know that Apple developed the patterns they use, in order to allow very small teams to create high-Quality, high-performance apps, in very short time (again, because I've talked to some of the folks involved in writing UIKit). People like me, working the way I do, were what they had in mind, as they developed their frameworks.
SwiftUI looks pretty cool. I haven't used it much [yet], because I have yet to be convinced that it is suitable for ambitious, shippable projects. I'm waiting for it to develop a bit of momentum. At first glance, it doesn’t seem to be designed for MVC (but it may work great. I don’t know enough about it, yet, to be sure). I’m happy to learn up on whatever methodology works best for it. I learn quickly, and adapt extremely well. Been doing exactly that, for quite some time.
Nope, I just think you're wrong, sorry it came across as something more than that! I don't think this has much to do with the specific qualities of MVC (they're a lot of good things about MVC) or the problems of newer approaches (declarative UI doesn't fit everything, implementations are newer and buggier, etc). The 'made for chumps, not artistes' mindset/explanation ends up being statistically wrong, over the medium-ish+ term, just about all the time (60% of the time!) - a pretty great track record of wrongness which is interesting and useful in itself.
I'm sorry. I must be thick. I still don't really understand. It appears as if I am being told that I'm an "arrogant arteest."
That seems pretty insulting, to me. It might help, if you reached out, personally, instead of deciding my personality, based on a single post on an internet forum. I’m actually a pretty decent chap, and I’m not particularly up for online catfights. BTDT. I’m an old troll, and feel that I have some atonement in store.
> And, I know, for a fact, that some of these patterns are used for exactly the reason that I stated.
You've gone from "I strongly suspect" in previous comment, to "I know, for a fact"...
New methodologies are not necessarily designed for large teams of "unskilled engineers", just like old methodologies were not necessarily designed for "one or two skilled engineers"...
Actually, "I strongly suspect" is a rhetorical device that I use. I deliberately use ambiguous language, because exact language is often taken as confrontational.
As it turns out, I needn't have bothered. This was declared a p****ng match, anyway (I didn't mean it that way).
I guess the difference is who gets upset.
I wasn't talking about how they were designed (I apologize for unclear language in my initial posit that indicated that). I was talking about how they are used.
> I strongly suspect that some of the new development patterns (I won't name them, because holy wars) were developed specifically to break up projects that are really best done by one or two skilled engineers, into ones done by a fairly large team of relatively unskilled engineers.
I've always thought of microservices (or services) as a way to make your organization rather than your code scale. Past a certain size, you won't have an uniform group of developers. According to Conway's law, this will impact your codebase. Better embrace it in your organization.
I write fairly humble apps, though. If things got a lot bigger, I'd hire someone to do bigger work.
In any case, it's really easy to toss out a codebase that took one guy, two days to write (I do exactly that, all the time). The advantage that I have, is that I write really good code, in those two days (feel free to check out my work).
The big app that I'm writing, is a native Swift app. The server is written in PHP. This is not because there's an inherent value in that, but it is because that is what I do, and we can't get anyone else to do the work for free.
A lot of these architectures you're referring to are intended to scale a team and solve collaboration issues, some intend to allow for easier automated testing or configuration etc. I don't think it's necessarily a bad thing either if they're designed in a way that larger teams of varying skill levels can contribute.
If you're busting out an iOS app in a day alone then of course MVC is going to be fine for your needs.
Thank you! My team recently implemented a section of the app with SwiftUI in 'MVVM' and it is a unmaintainable tangled mess. We should have used something more like MVC.
I'm putting the finishing touches on my second app in about a month and a half. It's a "total rewrite" app; just like the previous one (which is already out there, and has had over a thousand downloads already).
I did these apps alone. After this one is out the door, I'll return to the app I've been working on for a year and a half. These were just "side trips," because I was getting burned out.
UIKit was designed as an MVC framework. If you use a different pattern, then "you're holding it wrong." You are using the framework in a manner for which it was not designed.
That is not always bad. I can't actually think of any examples, right now, but I'm sure that some of the new methodologies are more effective.
I strongly suspect that some of the new development patterns (I won't name them, because holy wars) were developed specifically to break up projects that are really best done by one or two skilled engineers, into ones done by a fairly large team of relatively unskilled engineers.
Might work out. I don't know. That's not how I work. YMMV.