Last post May 16, 2011 06:09 PM by atconway
May 10, 2011 02:35 PM|geek.rutherford|LINK
Straight to the point, the number of technologies and patterns available to developers seems to have exploded over the past few years. I have always tried to stay current on the latest and greatest, learning what I deemed applicable to my career and best
Most recently I've begun learning MVC 3 in order to port an application from Web Forms. While at it I figured why not investigate the Entity Framework in order to improve my data access layer. This led me down a rabbit hole which thus far has presented
an ever growing number of questions and at times confusion.
In the past my mantra has been to keep things as simple as possible. I've found it provides for better maintainability not only individually but for the entire team. However what I persistently see are examples of architectures which utilize a multitude
of different technologies pieced together which on the surface sound great, but in practice would be quite complex even to an experienced developer.
Am I alone in this observation?
May 10, 2011 03:08 PM|HeartattacK|LINK
Yes, there are too many "architectures" out there. Yes, stuff should be much simpler than 20 layers of abstraction for the hell of it. Consider looking into CQRS + Event Sourcing (just google it). These patterns take the focus away from the technology and
towards solving business problems in a maintainable, traceable way.
May 11, 2011 05:49 PM|abhisheks|LINK
Totally agree with you both.
My observation has been patterns has been there for ages now. They have not exploded, but rather evolved, any patterns that developers use has the same basic seed that was there 20 yrs earlier.
Technologies and tools have exposed(used is probably a better word) these patterns to make it look like everything can be done with one click of the button, and whereas those tools are great for may be some general cases, those tools can not handle everything.
Once a company invest on these tools, they want everything to work with this tool and then comes the part of those gray holes, where one size fits all is the mantra.
Then you have developer who know what they are doing(I actually define those developers as people who try to keep things as simple as possible) vs wanna be developers who love to obfuscate any tools that's in their hand by trying to use design patterns without
much knowledge on how to tackle a given problem domain. These wanna be developers know how to implement a given pattern, but these developers do forget to read the sections in a book where the author is talking about applicability of those patterns for a given
Just my cent.:)
May 12, 2011 06:59 PM|atconway|LINK
Am I alone in this observation?
Yes you are, how dare you ask that question here on the Architecture
forum. Why I just wrote a book on the 'MV-XYZ' pattern. Don't you know, everyone is using it. (note sarcasm and humor...hey we developers can be funny too right?)
A quote of mine that I mention at least monthly either to myself or someone in the industry nowadays: "I feel like a jack of all trades and a master of nothing." This backs your comments about all of the new architectures, technologies, and wizbang storm
clouds and walkie talkies all this stuff goes on. In the past year or so I am trying to focus in on a few key technologies and methodologies and not get too sidetracked by every new technology that comes out (LightSwitch, WebMatrix, WF 4.0, WP7, etc., etc.)
Most decent books on object oriented programming, architecture, or design patterns have some mention of how you use the described methodologies to help making solve a problem
easier, and not for the sake of doing it. You can help weed through a lot of the B.S. using architectures and design patterns by implementing the ones that make sense. This only happens after you have gained a thorough understanding of it 1st, and
this is not always easy to do. Therefore we all have at 1 time or another (I know I have) implemented a pattern that was overkill because I learned it and wanted to try it out. In retrospect it was too much and didn't make solving the problem any easier.
So my advice, stick to what you know and move forward at a comfortable pace to new technologies, architectures, etc. when
you feel it is time and when it makes since to accomplish a project or task. Try not to get too caught up in the bleeding edge that this world (especially ours) makes us feel compelled to be a part of, and stick to what works and is best. Not just
for the sake of doing it. And no worries, mistakes in decisions about what and when to use an architecture
will be made. Just use that experience to make a better decision next time.
Hope this helps!
May 13, 2011 03:29 PMemail@example.com|LINK
Thank-you for saying this. THERE IS TOO MUCH ARCHITECTURE/ENGINEERING.
I have been in this field for 14 years now, I started with VB4 + windows development. (Non OO, procedural languages) Then VB5, VB6, Windows + Classic ASP development (Non OO, procedural languages).
I grew into (for the first time) understanding Objects with DOT NET 1.0 + 1.1. I learned the code-behind model of ASP.NET. Everything was going fine, and we had simple ways of connecting to a database, and Updating a database, connecting to disparate databases
with a data layer, everything was fast and simple (If you knew how to do it, and keep it simple (for reference see: Imar Spaanjaars Building Layered Applications with ASP 2.0).
What I noticed around ASP 2.0 time, was that the Java people were being recognized for using tools and patterns for years by a few DOT NET Developers that would stray from the Microsoft Mantra. Now, People are going overboard, using SOA for two databases
on the same server! Using "Factory" pattern to obfuscate something for the heck of it and to put it on their resume. It is time for the masses to speak out against using all this stuff just for the sake of using it! The smart developers will keep up on
patterns, but not necessarily jam all of them into every project. Your company, its IT staff, its time to market, its developers' abilities, ALL of these things factor into what/when/why/how you should PATTERN stuff. Not many books mention that, or spend
much time on telling you that part of the FACTOR. Thanks for the sanity check. KISS - Keep it simple stupid, only introduce complexity when the job at hand is already complex and needs to be SIMPLIFIED ! Don't SOA the SOA box !
May 13, 2011 08:15 PM|HeartattacK|LINK
While it's true that many projects are way too architecture heavy (specially with NCITAs [Non-coding Ivory Tower Architects), that doesn't necessarily mean there cannot be too little of it as well. Fundamental design choices can be the difference between
maintainable code and 20K WTFs/minute. The trick is to let architecture guide like a north star - not criplingly restrictive, just suggesting progress. And letting that architecture mature as knowledge, experience etc. grows. And apply improvements from project
to project based on battle scars. That will lead to "architecture" that's actually necessary rather than 15 layers of abstraction where 14 layers simply delegate to the next one and YAGNI features making the source code as kryptic as can be.
May 16, 2011 06:09 PM|atconway|LINK
Here is a link you might enjoy on topic:
Architecture astronauts take over: