The framework myth
-
Indeed. 1. Code Reuse doesn't require frameworks. Frameworks are great if you are stamping out the same application again and again. Otherwise, use building blocks. Frameworks give the illusion to be "easier to use", though, because they attempt to encapsulate the application architecture. This is all good and fine until Change Request #3. With building blocks, the library client still needs to understand the architecture. 2. Don't Repeat Yourself is not an absolutum. When folding multiple implementations into a single method, the implementation complexity grows due to additional cases and error conditions need to be handled. One statistic concluded that having the same code in only two places alone is not a good indicator for refactoring. 3. The best advise about frameworks I heard is this: Before you write a game engine, write at least three different games.
FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchy -
Loved the one section title, "Worser Is More Gooder". :-D
Chris Meech I am Canadian. [heard in a local bar] In theory there is no difference between theory and practice. In practice there is. [Yogi Berra] posting about Crystal Reports here is like discussing gay marriage on a catholic church’s website.[Nishant Sivakumar]
-
In fact, I have a more extreme opinion: frameworks are bad - period. I've never seen a half-decent one yet, regardless of the programming language or platform. The only sane way to reuse code is libraries. If someone is unsure of the difference between a library and a framework, here is a short explanation[^]. Basically, a framework imposes a design on applications, whereas a library does not.
-
I see no reason why anybody should argue with it. It's one of the reasons that I stopped referring to Goldlight as a framework and started calling it a set of libraries. That's exactly what it is - a set of reusable components that you can use if you want, and don't have to if you don't - nothing about it forces you down a particular route because I didn't want to take on the responsibility of figuring out how YOU want to do things.
I'm not a stalker, I just know things. Oh by the way, you're out of milk.
Forgive your enemies - it messes with their heads
-
There are many things that are preached like religious dogmas. The problem is, that none of those things automatically make your code good. Following those dogmas without thinking turns you into a cargo cult programmer who can recite every golden rule in the book but can't really tell you why. And cargo cult programmers produce some of the most sinister code horrors, thinking it's the best ever written because they applied their entire arsenal of silver bullets. If a framework exists and suits your needs well, then use it. If it does not fit your needs, then don't. It is as simple as that. Each new project has its own new requirements and nobody can foresee all of them when designing a framework. Instead of one monolithic framework, I would recommend a modular approach, where every module is designed for one (and only one) specific recurring task.
"I just exchanged opinions with my boss. I went in with mine and came out with his." - me, 2011 ---
I am endeavoring, Madam, to construct a mnemonic memory circuit using stone knives and bearskins - Mr. Spock 1935 and me 2011 -
Well, the "take away" from this article is probably something we all know: the current software development process is broken, and instead of figuring out how to fix the process, we instead reach for another tool, oddly enough created by the same (broken) process! As some of you know (Marc steps up to the soapbox) I do a lot of client-server development, and my personal experience is that I and the team were doing the same things over and over again: creating the DB schema, creating objects to mirror the schema, creating SQL statements to work with the schema, creating business logic for application requirements, creating UI's so the user could (ultimately) interact with the schema, creating reports that mined the data in the schema. Blech. I don't think I've created a framework, I suppose I've created a set of tools in my one-man broken process (since that's the only thing I know) to address what I felt was broken in the above process. And the result is a different way of working and of course has a new set of problems. But I and people that use it like it better because it actually does improve the ease of creating the application and maintaining it. Really, I did try to fix the process! So, when the author writes: The problem is that there are plenty of good ways already, ways that those developers are already trained in and have spend years mastering, and you are not really as clever as you think you are. My answer is no, there actually aren't plenty of good ways already. Ways == process and we know the process is broken. There are actually very, very few good ways and most of us have been trained in these bad ways. You will also alienate and drive away all of your good developers, leaving you only with the not-so-great developers that really don’t have any better options Not in my experience. The good developers love it because my process free them from the mundane BS of development, and the good little bad little develoerps, the ones that have learned the plenty of good ways and are therefore actually bad developers, yup, they leave. Good riddance! The whole Atlas Shrugged paragraph, you could replace "framework" with "monolithic application" and you realize the same problems happen. It's the process, not the tools, not the code even. Be honest. Try to be objective. If you find yourself getting the slightest bit excited about the idea of building a framework, then back off; you are not thinking clearly. Heh. I should write, in Eckhart Tol
-
Indeed. 1. Code Reuse doesn't require frameworks. Frameworks are great if you are stamping out the same application again and again. Otherwise, use building blocks. Frameworks give the illusion to be "easier to use", though, because they attempt to encapsulate the application architecture. This is all good and fine until Change Request #3. With building blocks, the library client still needs to understand the architecture. 2. Don't Repeat Yourself is not an absolutum. When folding multiple implementations into a single method, the implementation complexity grows due to additional cases and error conditions need to be handled. One statistic concluded that having the same code in only two places alone is not a good indicator for refactoring. 3. The best advise about frameworks I heard is this: Before you write a game engine, write at least three different games.
FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchyI fully agree. There are no silver bullets which automatically make everything nice and well. And down below I recommended the same approach, I just called them modules and not building blocks.
"I just exchanged opinions with my boss. I went in with mine and came out with his." - me, 2011 ---
I am endeavoring, Madam, to construct a mnemonic memory circuit using stone knives and bearskins - Mr. Spock 1935 and me 2011 -
I have been against custom frameworks for years. The Microsoft .NET framework provided the only framework I really need. Sure, I rewrite some code, sure there are occasions on other projects where I use copy-paste inheritance but I don't have to spend three hours figuring out how to write an xml file to do a task.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. I also do Android Programming as I find it a refreshing break from the MS. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost
-
In fact, I have a more extreme opinion: frameworks are bad - period. I've never seen a half-decent one yet, regardless of the programming language or platform. The only sane way to reuse code is libraries. If someone is unsure of the difference between a library and a framework, here is a short explanation[^]. Basically, a framework imposes a design on applications, whereas a library does not.
Frameworks are ok when you are repeatedly creating the same application type (say, customized point of sales apps) with mostly fixed customization points. The tendency to write frameworks instead of libraries is probably exactly the temptation to encapsulate the application design, so your code monkey don't need to understand that.
FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchy -
I fully agree. There are no silver bullets which automatically make everything nice and well. And down below I recommended the same approach, I just called them modules and not building blocks.
"I just exchanged opinions with my boss. I went in with mine and came out with his." - me, 2011 ---
I am endeavoring, Madam, to construct a mnemonic memory circuit using stone knives and bearskins - Mr. Spock 1935 and me 2011I like "building blocks" because it is supposed to be not yet watered down like module, library, or wrapper - and should suggest a lego-like application construction. In my experience, making the individual modules "good enough" often requirese severe violation of YAGI, and a lot of smarts still has to go into the glue / plaster, though.
FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchy -
Well, the "take away" from this article is probably something we all know: the current software development process is broken, and instead of figuring out how to fix the process, we instead reach for another tool, oddly enough created by the same (broken) process! As some of you know (Marc steps up to the soapbox) I do a lot of client-server development, and my personal experience is that I and the team were doing the same things over and over again: creating the DB schema, creating objects to mirror the schema, creating SQL statements to work with the schema, creating business logic for application requirements, creating UI's so the user could (ultimately) interact with the schema, creating reports that mined the data in the schema. Blech. I don't think I've created a framework, I suppose I've created a set of tools in my one-man broken process (since that's the only thing I know) to address what I felt was broken in the above process. And the result is a different way of working and of course has a new set of problems. But I and people that use it like it better because it actually does improve the ease of creating the application and maintaining it. Really, I did try to fix the process! So, when the author writes: The problem is that there are plenty of good ways already, ways that those developers are already trained in and have spend years mastering, and you are not really as clever as you think you are. My answer is no, there actually aren't plenty of good ways already. Ways == process and we know the process is broken. There are actually very, very few good ways and most of us have been trained in these bad ways. You will also alienate and drive away all of your good developers, leaving you only with the not-so-great developers that really don’t have any better options Not in my experience. The good developers love it because my process free them from the mundane BS of development, and the good little bad little develoerps, the ones that have learned the plenty of good ways and are therefore actually bad developers, yup, they leave. Good riddance! The whole Atlas Shrugged paragraph, you could replace "framework" with "monolithic application" and you realize the same problems happen. It's the process, not the tools, not the code even. Be honest. Try to be objective. If you find yourself getting the slightest bit excited about the idea of building a framework, then back off; you are not thinking clearly. Heh. I should write, in Eckhart Tol
Ask ten programmers for opinions and you will get at least twenty answers. That's good, because a developer must be able to solve problems. Indeed they must like solving problems. It will be hard work to convince any random group of developers to stop solving the problems themselves and accept your solution.
"I just exchanged opinions with my boss. I went in with mine and came out with his." - me, 2011 ---
I am endeavoring, Madam, to construct a mnemonic memory circuit using stone knives and bearskins - Mr. Spock 1935 and me 2011 -
In fact, I have a more extreme opinion: frameworks are bad - period. I've never seen a half-decent one yet, regardless of the programming language or platform. The only sane way to reuse code is libraries. If someone is unsure of the difference between a library and a framework, here is a short explanation[^]. Basically, a framework imposes a design on applications, whereas a library does not.
So .net isn't a framework? OK, cool.
-
I liked the article, and agree entirely. I create libraries of reusable code - sending email, extension methods, and other specifically targeted methods/classes. Beyond that, I have no "framework". If I need code that I've already written that isn't in the current project, I copy/paste and try to resist the urge to "normalize" the code to fit more situations. A lot of my code reuse is merely deriving from existing classes to add needed funcitonality.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997 -
Ask ten programmers for opinions and you will get at least twenty answers. That's good, because a developer must be able to solve problems. Indeed they must like solving problems. It will be hard work to convince any random group of developers to stop solving the problems themselves and accept your solution.
"I just exchanged opinions with my boss. I went in with mine and came out with his." - me, 2011 ---
I am endeavoring, Madam, to construct a mnemonic memory circuit using stone knives and bearskins - Mr. Spock 1935 and me 2011CDP1802 wrote:
Ask ten programmers for opinions and you will get at least twenty answers.
And maybe one of them will actually be a good answer. ;)
CDP1802 wrote:
It will be hard work to convince any random group of developers to stop solving the problems themselves and accept your solution.
Oh, there's no end of problems to be solved. I think there's a confusion between solving problems we know how to solve, and actually solving problems we don't know how to solve. The latter requires actual intelligence, stepping outside of our comfort zone, being willing to accept failure, and so forth. A lot of time is wasted on the former and not enough time is spent on the latter. Marc
-
So .net isn't a framework? OK, cool.
PIEBALDconsult wrote:
So .net isn't a framework?
It isn't really. The reusable part is named Base Class Libraries which is a far more appropriate name.
-
Frameworks are ok when you are repeatedly creating the same application type (say, customized point of sales apps) with mostly fixed customization points. The tendency to write frameworks instead of libraries is probably exactly the temptation to encapsulate the application design, so your code monkey don't need to understand that.
FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchypeterchen wrote:
Frameworks are ok when you are repeatedly creating the same application type (say, customized point of sales apps) with mostly fixed customization points.
I know what you are talking about and in theory I agree. The problem is that an application often goes beyond the limits of the original framework design and then the game "how to cheat my framework" begins.
-
Outside of the .NET Framework I'm using for the Framelet approach. A framelet represents a functional unit and - Is small in size - Does not assume main control an application - Has a clearly defined simple interface Further reading: Framelets— Small and Loosely Coupled by Wolfgang Pree & Kai Koskimies[^]
Cheers, Jani Giannoudis
Latest article: Time Period Library for .NET
-
I have been against custom frameworks for years. The Microsoft .NET framework provided the only framework I really need. Sure, I rewrite some code, sure there are occasions on other projects where I use copy-paste inheritance but I don't have to spend three hours figuring out how to write an xml file to do a task.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. I also do Android Programming as I find it a refreshing break from the MS. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost
Ennis Ray Lynch, Jr. wrote:
The Microsoft .NET framework provided the only framework I really need.
That's because ".NET Framework" is not really a framework at all, despite the name. It is a set of libraries.
-
Well, the "take away" from this article is probably something we all know: the current software development process is broken, and instead of figuring out how to fix the process, we instead reach for another tool, oddly enough created by the same (broken) process! As some of you know (Marc steps up to the soapbox) I do a lot of client-server development, and my personal experience is that I and the team were doing the same things over and over again: creating the DB schema, creating objects to mirror the schema, creating SQL statements to work with the schema, creating business logic for application requirements, creating UI's so the user could (ultimately) interact with the schema, creating reports that mined the data in the schema. Blech. I don't think I've created a framework, I suppose I've created a set of tools in my one-man broken process (since that's the only thing I know) to address what I felt was broken in the above process. And the result is a different way of working and of course has a new set of problems. But I and people that use it like it better because it actually does improve the ease of creating the application and maintaining it. Really, I did try to fix the process! So, when the author writes: The problem is that there are plenty of good ways already, ways that those developers are already trained in and have spend years mastering, and you are not really as clever as you think you are. My answer is no, there actually aren't plenty of good ways already. Ways == process and we know the process is broken. There are actually very, very few good ways and most of us have been trained in these bad ways. You will also alienate and drive away all of your good developers, leaving you only with the not-so-great developers that really don’t have any better options Not in my experience. The good developers love it because my process free them from the mundane BS of development, and the good little bad little develoerps, the ones that have learned the plenty of good ways and are therefore actually bad developers, yup, they leave. Good riddance! The whole Atlas Shrugged paragraph, you could replace "framework" with "monolithic application" and you realize the same problems happen. It's the process, not the tools, not the code even. Be honest. Try to be objective. If you find yourself getting the slightest bit excited about the idea of building a framework, then back off; you are not thinking clearly. Heh. I should write, in Eckhart Tol
Marc Clifton wrote:
Heh. I should write, in Eckhart Tolle style, a book on non-attachment, non-resistance, and non-judgment when it comes to coding. How to remove the ego from the work. How we can all stop experiencing the pleasure of our "this code sucks" pain bodies. How to code with joy and enthusiasm, and be present in the now, so we do our work with quality
Whenever you write that book I might buy it. (Don't make it to thick. I have a job, a life on the side of it and I'm a father of a 7 month child)
