|
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 ![Java | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif) , 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)
|
|
|
|
|
I agree... and disagree. I think people far too frequently try to apply one set of rules to everything and, like most things in life where that one-rule attempt is made, that doesn't work very well. You are absolutely right that some companies rest on their laurels and don't take the opportunity to revisit their product (in whatever form) to prepare for the next stage in growth or evolution. However, it's also possible to become so obsessed with rewriting a software product in [pick the trendy platform of choice at the given moment] that you end up living in the past instead of actually planning for the future.
Personally I believe we have ALL written bad code at some point (whether we want to admit it or not). But we have also all (at least the more experienced devs in the forum) written code that was "good enough for the time" - platforms, languages, operating systems, databases, transports all change and all businesses have to deal with deadlines, budgets, competition, available technology and other factors such that we do the best with the tools and time that we have. That's not to say that there are those that don't have horribly written bloatware on platforms they should have never considered in the first case, but I just don't think it's safe to apply a single all-encompassing solution without knowing the details of the situation.
The main underlying factor in considering a rewrite is to make sure that the reasons for the rewrite have solid business foundations - not just the technological drive to build it again.
|
|
|
|
|
I agree but I wan't even necessarily talking about a rewrite of the same product.
Part of my point is that if you want to remain succesful you have to move on and in authoring software as in authoring books or movies that doesn't mean reediting your last film again and again it means starting again, with everything you learned up till now and creating something new. Whether it is the next film in a series (where you can reuse the costumes), the next platform for your application or a completely new book is a matter of what will work best in your circumstances.
To put it another way keeping a film franchise going for a time may be reasonable but trying to endlessly rerelease the same film would be a disaster. I think too many software companies fall into this trap and they often do so because the software they started out developing was done so badly from a technical point of view it's difficult to reuse anything from it or transfer the technology to a different scenario.
It always looks too expensive to start again with a blank sheet but I think the 'we did it once we can do it again' attitude that tends to be more prevalent in the US is very often what's needed and one reason along with working better in teams why they still lead the world in successful large scale software.
The key is perhaps in recognizing that part of the value gained from developing a succesful product is the experience of doing so and the best way to realize that value is develop another one. It also keeps the technical people interested so they don't leave.
"The secret of happiness is freedom, and the secret of freedom, courage."
Thucydides (B.C. 460-400)
|
|
|
|
|
Agree 110%.
Relating to a film franchise is a pretty good comparison (from a theoretical standpoint at least) - can you say "Hangover III"! Very little coming out of Hollywood these days is original.
|
|
|
|
|
"If you don't have time to do it right, when will you have time to do it over?"
|
|
|
|
|
Right does not mean pretty. If it works, it works. The problem with companies that wrote ugly code that worked is that they did not start planning for upgrades early enough and waited too long to rewrite things. The ugly codes that lasted are the ones where updates happen once a decade or so. Companies need to assess how long their code is expected to stay running and start refactoring and improving it midway through. Sadly, those that do go belly-up still make a lot of money for their upper-management, but customers and employees be damned.
|
|
|
|
|
"Right" includes maintainability.
|
|
|
|
|
I’ve written a lot of DirectX code and I’ve written about DirectX extensively. I’ve even produced online training courses on DirectX. It really isn’t as hard as some developers make it out to be. There’s definitely a learning curve, but once you get over that, it’s not hard to understand how and why DirectX works the way it does. Still, I’ll admit that the DirectX family of APIs could be easier to use. A few nights ago, I decided to remedy this. I stayed up all night and wrote a little header file.... A challenge to all of the “C++ is hard” or “DirectX is hard” arguments.
|
|
|
|
|
Do i need replication? Actually this question should be replaced with ‘Can I afford data loss?’. Naturally the answer is ‘Hell no! Losing the data would ruin my business!’ So could you afford to lose data from the last hour, last 15 minutes or last minute? Or maybe you need a zero data-loss solution? It's not enough to just enable replication in your database because if you want your data to be completely safe you must face a tough decision about what replication mode best fits your requirements. The choice isn’t easy but it pays off when your data is still accessible right after a disaster.
|
|
|
|
|
Database replication is sold to an unsuspecting public under false pretences.
The threat is that your company will go out of business if your database is lost and so you need to replicate it.
How are you going to run your business if you are in California and an earthquake strikes?
Your employees may have been killed in the earthquake. Or they may be busy trying to locate their loved ones.
I talked to a PG&E (Pacific Gas & Electric) company representative about getting a second feeder line to power our buildings in case an earthquake knocked out the one and only power line.
He said that would be the last of my worries. There was/is a 3' gas main 300 feet from my building. In case there was an earthquake centered around that, the gas pipeline would rupture and the resulting fireball would suck out all the oxygen within 500 feet.
Think about that before you talk about database replication.
|
|
|
|
|
Vivic wrote: How are you going to run your business if you are in California and an earthquake strikes?
The sameway that the company I work for does (even though Oxfordshire doesn't suffer from eathquakes).
We have an off site disaster recovery location (in a different town) that we hire out and have the business back up and running in 2 days, which is achieved by using off site backups and replication etc.
Every day, thousands of innocent plants are killed by vegetarians.
Help end the violence EAT BACON
|
|
|
|
|
We backed up our data on a second computer that did nothing but backups. It would be what the article's author calls semi-synchronous but considering that there were no users on the replication machine and the connection between the two computers was 100 mb/sec, I would say that it was pretty much synchronous.
We backed up the data daily onto DAT tapes... one tape could hold the entire database. The DAT tape was stored offsite. We had daily backups for 30/31 days, month-end tapes, and year-end tapes.
We didn't sign up for off-site disaster recovery location for the simple reason we could get a trailer with the computer (the size of a two-drawer file cabinet) and half a dozen terminals on our site or any other location within your two-day period.
It still doesn't answer the question: how do you run the business if the employees don't/cant show up.
modified 5-Jun-13 11:52am.
|
|
|
|
|
WE've got 50 employees and growing, So our parent company enforced that we prepared for such events.
Every day, thousands of innocent plants are killed by vegetarians.
Help end the violence EAT BACON
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
