February 15, 2017 at 9:45 pm
Comments posted to this topic are about the item Framework Fatigue
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
February 16, 2017 at 4:24 am
It reminds me of this video, We're Gonna Build a Framework to tune of "We Didn't Start the Fire" by Billy Joel. Demonstrates the churn!
February 16, 2017 at 6:16 am
At times I get both framework and database fatigue from going around in ever decreasing circles. The current buzzword is NoSQL. Two of us with over sixty years of SQL experience between us feel SQL is right for the application but are virtually ignored by the trendy NoSQL folks! Seeing they have suggested two totally different NoSQL databases, a document store and a graph one, the thinking is far from clear. Have also gone around the frameworks a bit. After some mock-ups Flask was dismissed and the choice was going to Django. With the NoSQL Flask is suddenly in the running again!
February 16, 2017 at 6:25 am
I really like all the options, but at the end of the day it's all about the right tool for the job.
Kind of referencing mjh 45389 with a similar experience, SQL Server can do the job, but there is no distributing processing. You have to constantly build up and up to scale. Not only that, you're paying around 7K per core to get up to 30 cores. You're talking hundreds of thousands of dollars to go up as opposed to out. This is not a bad deal, but you do have open source options that can be the right tool for the job too. This is where the frameworks and other data related tools comes into play. You have a buffet of options available.
The most recent selection I've made would be Flask and Azure Data Warehousing. Flask is a amazing framework for Python. Its minimal and easy to use for API creation, web app creation and more. Azure Data Warehousing is also an awesome platform to use. It's built on SQL Server engine, but has a NoSQL feel to the backend that scales within minutes across multiple machines.
Whatever the case, we shouldn't curse frameworks and more options for data. Yes, you can become fatigued trying to choose and support. But's good to have options than NO OPTIONS.
February 16, 2017 at 7:02 am
I try to avoid the latest and greatest framework fad when possible. (Years of just keeping up with Microsoft's offerings has educated me well.) Looking back over the last 15 years I think the major "frameworks" I still use regularly are SQL and ODBC. That, along the mainstream programming languages and tools, Commercial and OSS has kept me sane. I'm getting back into functional programming via F#, but that's not a fad if you consider it's based on decades of research and has roots in Lisp.
I don't develop web sites anymore so I've missed out on the 700 different JS frameworks and tools that have popped up over the last decade. At most I'm considering static site generators or secure, non-flashy tool kits instead of whatever the kids on the coasts are doing this week.
February 16, 2017 at 7:05 am
xsevensinzx - Thursday, February 16, 2017 6:25 AMI really like all the options, but at the end of the day it's all about the right tool for the job.Kind of referencing mjh 45389 with a similar experience, SQL Server can do the job, but there is no distributing processing. You have to constantly build up and up to scale. Not only that, you're paying around 7K per core to get up to 30 cores. You're talking hundreds of thousands of dollars to go up as opposed to out. This is not a bad deal, but you do have open source options that can be the right tool for the job too. This is where the frameworks and other data related tools comes into play. You have a buffet of options available.
The most recent selection I've made would be Flask and Azure Data Warehousing. Flask is a amazing framework for Python. Its minimal and easy to use for API creation, web app creation and more. Azure Data Warehousing is also an awesome platform to use. It's built on SQL Server engine, but has a NoSQL feel to the backend that scales within minutes across multiple machines.
Whatever the case, we shouldn't curse frameworks and more options for data. Yes, you can become fatigued trying to choose and support. But's good to have options than NO OPTIONS.
Think I will have to take a look at Azure Data Warehousing...
February 16, 2017 at 7:20 am
I have very mixed emotions because on one hand, when there is a lack of options, there tends to be a lack of thinking. But...I also have a lot of things that actually bring in money that get in the way of keeping up with the latest thing. I am hoping that a solid three options will shake out soon.
February 16, 2017 at 7:27 am
I loved that video rome4for. I had not heard of 3/4 of them. Of course I was raised on FORTRAN, BASIC, and graduated to Cognos Powerhouse and SQL Server. I feel like a dinosaur.
February 16, 2017 at 9:11 am
Unfortunately the framework evangelists seem to have no concern for legacy code. Rewriting websites every couple of years is a crazy expense.
...
-- FORTRAN manual for Xerox Computers --
February 16, 2017 at 9:18 am
jay-h - Thursday, February 16, 2017 9:11 AMUnfortunately the framework evangelists seem to have no concern for legacy code. Rewriting websites every couple of years is a crazy expense.
In all fairness to website development new(and powerful) features are still being added often enough that a complete rewrite might be justified every few years.
February 16, 2017 at 10:04 am
I believe that both jay-h and ZZartin are correct. The trouble I find is that too many people roll out new APIs even when it isn't justified.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
February 16, 2017 at 11:41 am
I completely agree with you. Every company I have ever worked for has been profit oriented, even the non-profits! So when it comes to spending money to educate the team on something new, most aren't willing to do so. For those who would argue that you can learn it on your own, I understand - but like Milton Friedman said, there is no such thing as a free lunch! It still costs something, either time spent learning instead of building, or personal time spent learning, which fatigues workers and results in burnout.
Add to that how development tends to jump to the newest concept because someone in marketing convinced someone in administration that "this will save you money", and you end up with most people in technology knowing a little about a lot, but rarely a lot about anything.
End result, the churn burns out staff, increasing turnover and decreasing quality. Since the frameworks are intended to (sold as) increase quality and productivity, the end result is frequently exactly the opposite of what was intended.
Some industries do a great job of slowing things down, to allow staff to become experts, and to eliminate as many defects (in whatever they build) as possible. Most don't.
Dave
February 16, 2017 at 11:43 am
Gary Varga - Wednesday, February 15, 2017 9:45 PMComments posted to this topic are about the item Framework Fatigue
Preach!
February 16, 2017 at 12:06 pm
ZZartin - Thursday, February 16, 2017 9:18 AMjay-h - Thursday, February 16, 2017 9:11 AMUnfortunately the framework evangelists seem to have no concern for legacy code. Rewriting websites every couple of years is a crazy expense.In all fairness to website development new(and powerful) features are still being added often enough that a complete rewrite might be justified every few years.
You said "might", and I am not debating that. I will say though, too often we rebuild just because we can. There is no value there. Does the current product work? Does it do what we need it to? Does it perform appropriately?
If so, I don't care how old it is!
I didn't include "is it secure" because we know it isn't, and we know the new code won't be either. In fact, the new code will likely just be worse. Example - Java and Flash are updated just about weekly, and every update just introduces new bugs, while occasionally someone finds a bug that has been around for a while but not yet made public. So rewriting an entire app/web site to make it secure doesn't measure up in my mind. Fix the bugs, don't start from scratch.
Dave
February 16, 2017 at 12:42 pm
One of the problems with frameworks is that people don't know where to stop. Many of them start out with a noble aim and tightly defined goal. Then someone suggests a minor modification that would allow something to be hacked together quickly for which the framework was never intended. Because it is a quick hack to cut a corner the modification is a done in a way that only achieves the short term aim. If it gets refactored the poor sod who does so quickly realises that the modification should not have been done in the first place. Being concientious they achieve a miracle and make it uncrap but not good.
Subsequent bolt ons and development just makes it worse. Eventually a light weight focused helper system turns into a massive complex impedimenter. Then someone quietly builds a small, light weight tightly defined replacement and the whole cycle begins again.
I know of a developer who considers a DAL to be a bit boring to write but not a major undertaking. By the time others have wrestled with an ORM and sort-of got it working he's finished the entire project.
I can remember designing a simple system to import and match data. An imperial decree went out that RDBMS mustn't be used because they were remnants from a bygone era. A couple of frameworks were going to be used for the job. I went on 2 weeks leave and expected the entire thing to be finished but the team was still trying to get the first framework operational, never mind actually building something with it!
I used the design as a learning exercise to teach myself Java and had a fully working prototype up and running in a couple of nights.
Viewing 15 posts - 1 through 15 (of 19 total)
You must be logged in to reply to this topic. Login to reply