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
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
-
who thinks he's whining about office politics? Seriously. "They're not written by anyone you know." "All use the customer object the same way" Blah, blah, blah. I've worked on big projects (300+ developers). I've seen major rearchs (decentralizing a customer database....then recentralize it...then decentralize it again!) The framework isn't the solution...it ain't even the problem.
-
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 2011Correct. I once worked at a company where some Java "wizards" came in and built a framework to "help" us build our core type of application, moving away from the "building blocks" method. We went from a shop where we could hire a broad range of skill levels (more junior devs would do the simpler types of setups) and simpler applications would be up in a matter of days to one where every implementation was a six-week slog through the mud, and we could only hire highly-skilled devs who could understand the complexity. Then nobody could figure out why our costs skyrocketed, and clients weren't willing to pay the extra amount. Now, to be fair, there were some notions in the framework that were good, and should have been brought in as building blocks. (They may have been, I've long since left). So, not to slag the notions, it was simply the execution of them. The article is right with the discussion of what they called Harvesting. Build a couple of things, and see what's common. I think the distillation of the article is something on the order of: unnecessary complexity is bad, and non-optimal simplicity beats optimal complexity almost every time.
-
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, 1997Saying it that way makes me think of a couple of things. 1) The notion of the framework is the notion that we must solve all problems right now, and I think that's where it gets off the road. As you build and notice normalizations, take the low-hanging fruit, but nobody's going to die if we don't totally normalize. If you solve all problems today, what will you do tomorrow? Plus, if you let it roll around in your melon a little bit, you'll probably think of a better way. 2) We I got to my current position, there was no consistency between applications, as we didn't have a domain layer. Everyone got raw data sets, and did with them as they pleased. Using the same kind of records from a table might implement totally different logic/data access/etc in a couple of different applications. I recognized the craziness of this and built and started building libraries to abstract these data sets into domain-type classes that the apps could reference. When accessing an object of type X, here's the API, the app builder doesn't have to worry about sprocs and business logic and so on. Anyway, I've been calling these libraries the "foundation", because we're going to build apps on top of them. Maybe that's a way to think of it, build a foundation for your apps to rest on, not a framework inside of which they must live. Although I don't like that terminology either, because a foundation (from the physical world) does imply a certain structure laying on top of it, since it's poured concrete. But, I can't think of another term I might like better.
