Yeah... that is another perspective... so how can I check whether I am applying SOLID or not, is there any way to check this?

But I had something else regarding Scott... when he was in Apple iOS 6 release was delayed... I've no idea about Microsoft

I've been also working in iOS app development since 2010 and I applied SOLID principles in project, and I and my team found that things are better than before...

Yes, now we are on bottom line of the whole discussion that is "your personal opinion", right... basically you and your team found difficulty while using SOLID, may be you guys did not applied all the principle in a correct way, because 300 line to 3000 lines, this is a really huge difference... it seems SOLID over engineered in your project... because the picture you are showing is not a fully correct...

But in a bigger project may be good idea will be designing UI through code and breaking down ViewControllers... So its all about approach and I totally agree KISS is always better, if developer has problem with applying other thing that really make your project complex.

Yes, in small project applying SOLID is a wrong decision... It is like that if you are building a 2BHK house, then you don't need super skilled electrician, plumber, carpenter, and all that... but if you building a big mall then you will need some good skills and some proven principles and patterns... same thing you can apply on small project vs bigger projects... In small project you can design your UI in XIB or Storyboard and write everything in a single view controller (simply)

This is really nice that Team KISS did the project just in 120hrs (15 working days) and Team SOLID took 1500hrs ie around 6 months S:Single responsibility O:Open closed L:Liskov substitution I:Interface segregation D:Dependency Inversion I am just wondering which part took that much time, well they must be using S for writing isolated component or modules, also O for adding new features, not sure about L and I, but D also must be there for inverting the dependency. Can you please elaborate?

Seniors think & design software before writing the code. ---> Absolutely And if we follow principle and pattern (of course in balanced way) than this is what we will not see in our projects: "everything becomes problematic and complex, expensive projects, delayed or cancelled projects, upset team members, difficult to scalability and maintenance" It's a other way around... well, everybody has their own experience....

This broken or non functional bi-cycle example will confuse other developers regarding over engineered code Vs applying XP, TDD, SOLID, SoC, etc.. in their code. Even new developers will hesitate to touch all these...

Both tyres can be tested independently, even in any other cycle also... so TDD is important here... The whole cycle also following O in SOLID, open closed principle... you can add new functionality in this bi-cycle like you can add horn, some kind of led lights in rings, carrier, and all that... same thing we should able to do in our code, we should be able to add new functionality without affecting our existing functionalities...

I was looking this bi-cycle again, it is not over engineered code, it seems broken code... you know over engineered code also works, but here your bi-cycle in non-functional, it not over engineered... still a good bi-cycle follows SoC, SOLID, TDD... both tyres has a single responsibility, if you work one first tyre there won't be any affect on second tyre, and this is also good in your code, if you touch one area of code other are won't be affected...

Yeah it is MV... and following some principles in balance mode not over engineered. You put things in isolation that is good.

This line doesn't make any sense "Don’t over-engineering just because you read “Uncle Bob” SOLID book and the book tell you need to over complicate. From my 20 years of experience, SOLID principles are a cancer." Instead, simply we can say don't over engineer your code. My point is that when developers go with these at least they understand about coupling, reusability, testability, maintainability, extensibility and all that, we should not directly avoid it in one shot.

Agreed, over engineering is not good but that doesn't mean we should avoid use of TDD, XP, SOLID, SoC, etc... it seems like that you are saying "drinking too much water can make you die" so "don't drink water". TDD is important but adding too much unit tests is dangerous. SoC: anyhow we are using here and there, even in your code things are in isolation, you have not coupled things together. XP is also important, part of Agile SOLID: as you mentioned above S is there in every architecture...

Well, this implementation looks good, but what you call this MV or Active Record or something else?