|
Seems like the argument is "bad developers shouldn't use frameworks, because bad developers don't use frameworks".
|
|
|
|
|
Good developers shouldn't use frameworks either.
|
|
|
|
|
Yes, good developers do not need Frameworks !!!
|
|
|
|
|
I'm sorry. This is an incoherent rant.
|
|
|
|
|
Bad developers should also never be allowed to BUILD frameworks. I've experienced the outcome from this first hand. It was horrifying.
|
|
|
|
|
|
LOL, been there! I once worked with a guy who was obsessed with frameworks, he wrote an in-house one that was critical to our business. Only, he never finished it, or any other project he started. It was a horror show of method stubs and debugging code and commented-out changes, and this was in production! He refused to fix any bugs or complete needed functionality, considering that someone else's job, so the other programmers were forced to work around the problems or make the fixes themselves.
He also liked to use frameworks for totally unnecessary applications, like for a simple SFTP client to pull an import file, a tool I was once forced to use. It was a ridiculous error-prone mess with objects being passed through seven layers of hell when there was no reason for abstraction in the first place. I ended up removing the reference to his code and just wrote some simple reliable code to do the basic SFTP pull (I suspect that he wanted me to use his tool so I would get tagged with ownership and maintain it for him--not it!).
As for the article, though, I'm not sure what the guy was getting at. Frameworks are tools, it depends on how they are used. That's true of all tools in programming, including the languages themselves.
|
|
|
|
|
Incoherent argument. What was the point? I've read a few of this person's posts and after reading them I'm always left with the feeling that they must be terrible to work with.
|
|
|
|
|
This is a useless argument that is there just to boost the author Adds income.
If one is a bad professional he shouldn't be doing it, period!
But life isn't as simple as this and we all know how it goes and we have to live with it.
Everyone at least once looked at he's own code some months later and thought:
"S**t! What was I thinking when I wrote this?!"
Architects
Here we're speaking about developers, but these are far from being the one that really weight on bad software at the end.
For me, bad Architects (or the lack of a defined architecture) can damage much more than a bad developer.
On top of the damage, a bad architecture is much harder to rollback than just a piece of bad written code.
Project Leadership
Bad of lack of project leadership leads to bad developers "perception".
You might be a good developer but if you don't have the right info to work with you might end up writing bad code and not even knowing it.
Frameworks
There's a lot to say about this but bottom line is that Frameworks are never the problem.
In fact they help to encapsulate logic that most of the time we would end up writing anyway so what's the problem?
The problem is the same as Googling and Copy/Paste. Using them blindly, without caring about what they really do underneath.
Of course, at the end it's easy to blame who actually stroke the keys and code the damn mess, but I've seen much more crappy software than crappy developers and this should mean something...
Cheers!
|
|
|
|
|
AlexCode wrote: Frameworks are never the problem.
I would beg to differ but MFC doesn't provide a way to do that with making a fool of yourself.
AlexCode wrote: Using them blindly, without caring about what they really do underneath.
Agree 100% but of course this can only be solved if the framework itself is transparent, open source and well documented.
I do framework development because it's hard and therefore a good way to learn. 10 years and I'm still learning exactly how hard it is.
"The secret of happiness is freedom, and the secret of freedom, courage."
Thucydides (B.C. 460-400)
|
|
|
|
|
Based on this article, I'd say bad writers shouldn't use blog engines.
|
|
|
|
|
Framework that can be used only by expert developers is probably not so good
|
|
|
|
|
The same goes for API's...
|
|
|
|
|
Too much judgemental boasting by this piece of blogger.
Or maybe he just wants to let everyone know that he knows about validation?
modified 20-Oct-19 21:02pm.
|
|
|
|
|
No, he really just wants the Adds income...
|
|
|
|
|
He should hit a nail on his head, this is a useless rant and on top of that incoherent.
|
|
|
|
|
Bad Developers Should NOT develop, in any case
|
|
|
|
|
At TechEd North America Microsoft announced a wave of products and services that will help customers embrace the “enterprise cloud era.” The next version of theirdata platform – SQL Server 2014 – is a key part of the day’s news. Designed and developed with our cloud-first principles in mind, it delivers built-in in-memory capabilities, new hybrid cloud scenarios and enables even faster data insights.
SQL Server 2014
Deependra
|
|
|
|
|
It's the bane of most programmers' lives - an unhandled exception causes your application or webapp to crash, an ugly dialog gets displayed to the user, and they come complaining to you. Then, somehow, you need to figure out what went wrong.... However, it's good that the program crashed. Or, more precisely, it is correct behaviour. An unhandled exception in your application means that, somewhere in your code, there is an assumption that you made that is actually invalid. Fail early, fail often... fail spectacularly if that's what it takes to learn.
|
|
|
|
|
I have now worked at a bunch of companies, and consulted for quote a few. I have looked at some pretty horrible code. Every company I visit with say the same thing: Yeah, but our code really sucks. It does not suck more than other code I have seen. It usually sucks about as much. Do a thought experiment: Of the ugly code you’ve seen,: when was it written? How long has it been alive? Most of the time, I have seen ugly code that started a good few years ago. Your hacky code is now a big business. Now you can make it pretty.
|
|
|
|
|
Nope, ugly code means your big successful company is about to miss the 'next big thing' or be so late to the party it costs eye watering ammounts of money to get in. If you're big and successful now you've got about 5 minutes to start doing it properly or you won't be big and successful any more. Yes you invested everything you had in that pile of hacks and it made you your first million. It won't make you your second million even if you invest everything you've now got in it. Sit down with an empty computer, take a deep breath, smell the , remember everything you learned last time and start again.
"The secret of happiness is freedom, and the secret of freedom, courage."
Thucydides (B.C. 460-400)
|
|
|
|
|
Matthew Faithfull wrote: Sit down with an empty computer, take a deep breath, smell the [Coffee] , remember
everything you learned last time and start again.
A company selling an ERP package named BPCS did exactly that.
It was about a $400 million company, if memory serves me right.
BPCS ran on the IBM AS/400.
They took the advice of programmers/consultants or whatever and decided to rewrite the whole thing under Unix.
The company went belly up a few years later.
Programmers will tell you that RPG is a bad language, that the future belongs to C, C++, Java or C++11.
Now they are telling you that the future belongs to Scala, Haskell, Clojure, or PHP, HTML 5, etc.
They all had a future that lasted 5-10 years. But for the power of stupid people in large numbers, these languages would not have lived one year.
Write a stable system that does its job well. You can continue using the software forever.
You don't believe me? Ask the Wall Street stock brokerages what language their trade accounting software is written in.
|
|
|
|
|
For them to have gone belly up assuming no overriding external factors several thing were very likely happening.
Their revenue from the old system was no longer great enough after a few years to sustain development of the new system which implies the old system was dying on its feet and or they were too late starting their new development.
If after several years they didn't have a system that worked on Unix and could make money then either they weren't doing it right or the product itself no longer had a market.
Perhaps they didn't recognize the difference in expectation levels between AS400 users and Unix users or perhaps things had already moved on so far they should have been targetting Android with a package of that scale instead
"The secret of happiness is freedom, and the secret of freedom, courage."
Thucydides (B.C. 460-400)
|
|
|
|
|
Matthew Faithfull wrote: For them to have gone belly up assuming no overriding external factors several
thing were very likely happening. Their revenue from the old system was no
longer great enough after a few years to sustain development of the new system
which implies the old system was dying on its feet and or they were too late
starting their new development. If after several years they didn't have a
system that worked on Unix and could make money then either they weren't doing
it right or the product itself no longer had a market.
None of your assumptions is correct.
They were selling a very well respected ERP system and had hundreds of customers.
Total incompetence of the new product development team is what did them in. That, plus the arrogance that writing in C under Unix is the Holy Grail. Those idiots were being kept on the payroll by the revenue generated by the original RPG-based software.
By the way, I used software developed in 1983 on a System/38 written in RPG. That software could handle multiple currencies. Not Oracle ERP in 1989 when it was being touted as the Unix alternative.
Matthew Faithfull wrote: Perhaps they didn't recognize the difference in expectation levels between AS400
users and Unix users
Quite possibly.
My colleague had this to say about Unix systems engineers: "Their idea of service is turning the computer on at 9 am and turning it off at 5 pm."
On the other hand, the IBM AS/400 constantly runs self-tests and automatically reports potential failures directly to the factory, going so far as to place orders for replacement parts if the system is under maintenance by IBM. The parts are delivered to the local Customer (Service) Engineer with instructions as to which customer is supposed to have the parts installed.
Not bad for a machine put into service in 1987.
It also always re-uses he space used by deleted records so there is almost no need to reorganize (unload-reload) the database.
Any Unix box does that today?
In fact, there is no role for a Database Administrator (DBA) in an AS/400 shop.
Can you say that about Oracle, SQLServer, Ingres, Postgres, Informix, etc?
Before you diss any computer/OS/database, do a bit of work finding out its capabilities.
But then, if you get brainwashed in college, there is no hope for you.
modified 5-Jun-13 14:30pm.
|
|
|
|
|
Vivic wrote: Total incompetence of the new product development team is what did them in.
Yes. As I said they weren't doing the Unix development right and the revenue from their existing product, however wonderful, was not enough to sustain that development long enough to produce a viable product probably because they weren't doing it right.
It wasn't really about what language was used however much you'd like it to be or they thought it was. It was, as you said, about incompetence.
It's perfectly possible to create a great database and a fantastic ERP system in C even on Unix. The fact that no one seems to have done so yet is a tragedy for sure but that doesn't mean it cannot be done.
It might mean that it isn't a commercially viable thing to do. Simply not valuable enough for the effort it would take but that is another question and one they should have asked before they began such a project.
"The secret of happiness is freedom, and the secret of freedom, courage."
Thucydides (B.C. 460-400)
|
|
|
|
|