The framework myth
-
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)
-
I'm a frameless guy. I don't mind at all copy pasting. It's faster. It works. You can ship code. Hell that's how I learned most of the stuff I know(little actually) => copy paste CP(and competision) code and figure out why it wouldn't work as I wanted to. Coudn't agree more with Nemanjia and John.
All the best, Dan
-
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, 1997John Simmons / outlaw programmer wrote:
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.
Glad to hear I'm not alone in doing this. It is often much faster I've found.
"Life should not be a journey to the grave with the intention of arriving safely in a pretty and well preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming "Wow! What a Ride!" — Hunter S. Thompson
-
"This would be great if your sole goal was to create the best software in the world, but nobody is paying you to do that." Which is why I write my golden code on my own time.
-
When I was reading the article, and then everyone's responses, all I could think of was the government in Washington, DC, USA. I sure wish they would read this article and maybe understand that trying to dictate everything from the top down is NOT the best answer. A few (FEW) guidelines, standards, etc. are great to help people with their job (company level) or their state or city progress (government level). Amazing to me how family, company, and government problems, solutions, and methods seem to follow the same principles. But it seems like there is always someone, higher up, that thinks their ideas are so good, everyone under them should be forced to follow the bosses way of doing things. Sad.
-
When I was reading the article, and then everyone's responses, all I could think of was the government in Washington, DC, USA. I sure wish they would read this article and maybe understand that trying to dictate everything from the top down is NOT the best answer. A few (FEW) guidelines, standards, etc. are great to help people with their job (company level) or their state or city progress (government level). Amazing to me how family, company, and government problems, solutions, and methods seem to follow the same principles. But it seems like there is always someone, higher up, that thinks their ideas are so good, everyone under them should be forced to follow the bosses way of doing things. Sad.
When I posted the link to the article I was mostly agreeing with the author. But I thought there must be something good with frameworks that I had missed out. I never expected that basically all responses here would be along the lines of "Framework bad, library good". Which happens to be my opinion too.
-
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
+5 A most elegantly thoughtful reply, Marc, thanks ! best, Bill
"Many : not conversant with mathematical studies, imagine that because it [the Analytical Engine] is to give results in numerical notation, its processes must consequently be arithmetical, numerical, rather than algebraical and analytical. This is an error. The engine can arrange and combine numerical quantities as if they were letters or any other general symbols; and it fact it might bring out its results in algebraical notation, were provisions made accordingly." Ada, Countess Lovelace, 1844
