Over my 40 year career (thankfully retired now), I participated in 3 total rewrites.
The first two never produced anything and sucked up huge amounts of development resources.
The reason was identical both times:
New management wanted to take over a successful product and make a name for themselves.
They never really understood the original product and nor did the (largely) new development staff thay used.
The third rewrite project was a success.
The original management used most of the original development team to rebuild, from the ground up, the product.
While the rewrite took slightly longer than the estimates, the results were better than predicted.
The company was subsequently sold to a huge bank for hundreds of millions of dollars.
The team that built the original product and also did the rewrite still consider themselves a team, despite the fact
that most of us no longer work together.
IT'S ALL ABOUT THE TEAM
Full credit goes to the management for team building, which is the most important aspect of managing just about anything.
How can C++ be a bad language when it provided me with a very good income for the majority of my working life (after some years of COBOL) ?:-)
Looking at it from a more technical viewpoint, I really don't care so much about what language I use.
The most important aspect of software development is the design of the software.
C++ is just one of many languages used to implement a software design. Typically, bad workmen (or workwomen) blame their tools.
I can imagine some lawmaker somewhere declaring a halt to driverless cars after this accident.
I have already several articles suggesting that this should not be done because only more and more refinement of such a complex product will cause it to become viable. Also even with a few bugs, driverless cars are possibly already less accident-prone than humans.
As a software developer, I naturally side with continuing development.
Looking at the FAA gives a good model on how to proceed.
When an airplane crashes, the FAA sometimes grounds all models of that plane until the cause of the crash is determined and, if it was a technology error, will not allow the planes to fly again until the problem is satisfactorily resolved.
That would appear to be a measured response to this type of problem.
Don't halt all development. Don't proceed, ignoring the death(s).
Prohibit the specific driverless system from using the public roads until the problem is determined and an acceptable fix is made.
Just as cars have model years that receive approval, so should specific versions of driverless systems.
Then we can have official patches deployed on an as-needed basis, not just when a software engineer declares a bug has been fixed.
Very strict controls need to be in place to allow/deny a software/hardware update to a driverless system.
I don't want my car to be hacked and used as a killer weapon.
I can imagine some lawmaker somewhere declaring a halt to driverless cars after this accident.
I have already several articles suggesting that this should not be done because only more and more refinement of such a complex product will cause it to become viable. Also even with a few bugs, driverless cars are possibly already less accident-prone than humans.
As a software developer, I naturally side with continuing development.
Looking at the FAA gives a good model on how to proceed.
When an airplane crashes, the FAA sometimes grounds all models of that plane until the cause of the crash is determined and, if it was a technology error, will not allow the planes to fly again until the problem is satisfactorily resolved.
That would appear to be a measured response to this type of problem.
Don't halt all development. Don't proceed, ignoring the death(s).
Prohibit the specific driverless system from using the public roads until the problem is determined and an acceptable fix is made.
Just as cars have model years that receive approval, so should specific versions of driverless systems.
Then we can have official patches deployed on an as-needed basis, not just when a software engineer declares a bug has been fixed.
Very strict controls need to be in place to allow/deny a software/hardware update to a driverless system.
I don't want my car to be hacked and used as a killer weapon.
Here are some good practices for developers:
1. When a bug is reported in a group project, there are 2 types of people.
1.1 Without any investigation, a developer declares that it isn't his/her problem.
1.2 A developer who assumes it might be his/her problem and starts investigating.
I certainly prefer the latter. This isn't about ego, it's about code doing its intended job.
2. Developing always creates bugs.
Prolific developers create lots of bugs.
Developers should not be judged on the number of bugs.
Instead, they should be judged on the ratio of bugs versus the amount of code they produced.
A corollary to the above is that good developers create a minimum of code for a given requirement. More code = more bugs.
Beware of developers who create complex solutions to not-so-complex problems.
3. If your ego is so fragile that you cannot handle making mistakes, you are in the wrong job.
As long as you are creating code, you will always make mistakes.
The key thing is to find techniques/procedures to avoid making the same mistake ever again.
4. Good developers assume something will go wrong in their code and put in more code to handle "unexpected" scenarios.
When something fails, it is really good to have it not fail badly.
5. Test, test and test again. Never assume anything works properly.
I have had code fail several times after many years in production.
It took all that time before the circumstances were sufficient to trigger the obscure bug.
This also ties in with point # 1 above, it is very easy after a few years of success to assume it is bug-free, when it isn't.
6. NEVER stop learning.
You can always improve.
7. With so many opportunities for self-education, learn to choose the most useful ones.
Learning the intricacies of one niche application will cause you to be good at that job, but what happens if that job ends?
A resume of widely-used skills is good for employment longevity.
8. MOST IMPORTANT.
Love what you do. Take pride in your work.
If you don't love what you do, find a new job.
You cannot pay someone to take pride in their work, but you can reward them for doing it.
The US tax code documents would seriously challenge Ms. Linda Watson.
Not because you cannot read the actual words, more because you cannot understand their meaning.
Same with most government documents from just about any government.
Instead of voting for a representative, why not use computers to allow any registered voter to directly vote on bills?
We needed representatives long ago when communications were poor.
Quality communications should make these corrupt representatives obsolete.
You could exercise your right to vote on bills that you had a strong opinion about and ignore others that you didn't care about.
I retired at 59 after almost 40 years of software development, culminating in 10 years being part of a great team of people developing an algorithmic high speed trading system on wall st. I max-ed out my 401k every year and retired fairly early with enough money to live frugally (relative to previous lifestyle).
I now live in a quiet waterfront home surrounded by farmland.
I go crabbing and have caught 1502 crabs so far this season.
I roast coffee as a loss-making hobby/business. I wrote some custom software for my coffee business that tracks everything and even is hooked via a thermocouple on my roaster to record roasting profiles.
I traded a horrible commute for the following stress-free early morning ritual. On warm mornings, I drink coffee on my dock and watch the wildlife. On cold mornings, I drink coffee in my outdoor hot tub and watch the wildlife.
I tell my kids about the tortoise and the hare: the hare (almost) never wins. Slow and steady rocks.
So this is what can happen when a programmer gets old. Persevere and good fortune will happen. Good luck to you all.
Extrapolation of these results predicts that employees who work a 0 hour week will never take any sick days and will be extremely happy.
As a person in retirement, I can vouch for these results.
As someone who developed algorithmic and high frequency trading software, I fully agree that he is being singled out.
This guy was only doing what many of the large financial houses were and still are doing.
No pair of communications devices "has to share that information".
Data passed between my wireless mouse and my PC hopefully isn't sent to Logitech or Dell.
Data passed between my phone and my bluetooth speaker hopefully isn't sent to Bose or Verizon.
This data is sensitive enough that it should not be shared.
I suppose Hilary's private email server has saved her from being published by Wikileaks.
A previous poster suggested something incriminating would catapult Sanders into the DNC nomination spot.
If nothing actually incriminating is found, but something unfavorable is revealed, that would then help The Donald.
I'm glad to see iOS/2 is still alive.
Then again, I suppose I am biased as I worked on OS/2 for IBM a very long time ago.
I thought it looked very good versus the competition (Win3).
Being a huge fan of open source, I have been using Linux for a very long time now.
In fact I have always preferred Unix variants over anything else almost since I started working 45 years ago.
It was a breath of fresh air versus IBM mainframes where I started.
Wouldn't it be nice (a naive thought) if we had a politician who:
1. We could trust
2. Put the country's best interest above his/her own
3. Wasn't in the pockets of the rich
Instead we have trump and clinton.
Maybe they should get married.
They both are the exact opposites of points 1 thru 3 above.
I wonder why people are feeling they are not represented?
It's not what you know that will necessarily get you a new job.
It's not who you know that will necessarily get you a new job.
It's both plus having the ability to communicate in a reasonable manner.
When you are "experienced" and have quite a few years of development behind you, a decent developer will have built up a list of friends from previous or current jobs. Hopefully, these friends respect your ability to develop. When it comes time to obtain a new job, hitting up those friends is an invaluable resource. I have hired several colleagues from previous encounters in this manner. I have even hired the same guy twice. Each time I moved jobs, I pulled him in behind me. I have also been hired twice thru personal references myself.
Just think about it. Do you think an interview is much more than a crapshoot? You are trying to judge the suitability of a candidate based upon a few hours of interaction. Wouldn't you rather judge someone based upon their past performance of which you (or a friend you trust) are familiar, having previously worked with them?
I'm not saying that an old dog shouldn't learn new tricks. Far from it. It's every developer's responsibility to maintain their skill set. I am extolling the virtues of building a network of past/current colleagues who might be of help to you in the future, just as you might be of help to them.
So we are going to pay for a nuclear freight train to nowhere?
Couldn't we instead use the money to improve the existing rail network to encourage humans to use it?
The rail service in this country is such a joke that most people choose to pay between 3 and 4 dollars a gallon for gas, increasing pollution and funding the arms buildup in the middle east.
Much of the foreign interference offered by this country's government results in the reverse of what they were trying to achieve.
To meddle in something that is none of your business merely tends to give credibility to whatever you disagreed with in the first place.
“Never argue with an idiot. They will only bring you down to their level and beat you with experience.” - George Carlin.
“Never argue with a fool, onlookers may not be able to tell the difference.” - Mark Twain.
So if Iran or wherever wants to pass stupid edicts, just let it go ahead.
Have some respect for Iranians to recognize a horse's ass for what it is.
If a stupid government passes a sufficient number of dumb edicts that they eventually make themselves irrelevant.
Or maybe we should interfere and start another war which would surely help support a dumb regime (on both sides).
Typed www.brownlist.com URL into my browser and after a long wait got:
Server Error in '/' Application.
Runtime Error
Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons).
[...and some more]
Slashdotted?
Eat your hearts out.
I'm recently retired and loving it.
I'm currently building a kayak rack in my back yard without any deadlines.
Sometimes I just put down the tools and paddle off to check my crab pots.
At the start of every day I sit on my patio overlooking the water, drink my coffee and decide what (if anything) I will do for the rest of the day.
I wish I could have retired 40 years ago.
So long and thanks for the fish.
My wife connects waaaaay too many devices to a single power point by using multi-way adaptors.
Now she will be able to daisy chain various phones, laptops, portable speakers etc,.
Can you blow a USB fuse in this new standard?
Just send a predator and take out the Equadorian Embassy in London.
Sure, there will be some collateral damage.
Get the spin doctors to suggest it was Sweden that did it.
Slashdot Mirror
Over my 40 year career (thankfully retired now), I participated in 3 total rewrites.
The first two never produced anything and sucked up huge amounts of development resources.
The reason was identical both times:
New management wanted to take over a successful product and make a name for themselves.
They never really understood the original product and nor did the (largely) new development staff thay used.
The third rewrite project was a success.
The original management used most of the original development team to rebuild, from the ground up, the product.
While the rewrite took slightly longer than the estimates, the results were better than predicted.
The company was subsequently sold to a huge bank for hundreds of millions of dollars.
The team that built the original product and also did the rewrite still consider themselves a team, despite the fact
that most of us no longer work together.
IT'S ALL ABOUT THE TEAM
Full credit goes to the management for team building, which is the most important aspect of managing just about anything.
How can C++ be a bad language when it provided me with a very good income for the majority of my working life (after some years of COBOL) ? :-)
Looking at it from a more technical viewpoint, I really don't care so much about what language I use.
The most important aspect of software development is the design of the software.
C++ is just one of many languages used to implement a software design. Typically, bad workmen (or workwomen) blame their tools.
Oh gosh! A corrupt politician?
Who could have forseen this?
But why are we focusing specifically on Donald Drumpf?
Aren't all politicians corrupt?
I can imagine some lawmaker somewhere declaring a halt to driverless cars after this accident.
I have already several articles suggesting that this should not be done because only more and more refinement of such a complex product will cause it to become viable. Also even with a few bugs, driverless cars are possibly already less accident-prone than humans.
As a software developer, I naturally side with continuing development.
Looking at the FAA gives a good model on how to proceed.
When an airplane crashes, the FAA sometimes grounds all models of that plane until the cause of the crash is determined and, if it was a technology error, will not allow the planes to fly again until the problem is satisfactorily resolved.
That would appear to be a measured response to this type of problem.
Don't halt all development. Don't proceed, ignoring the death(s).
Prohibit the specific driverless system from using the public roads until the problem is determined and an acceptable fix is made.
Just as cars have model years that receive approval, so should specific versions of driverless systems.
Then we can have official patches deployed on an as-needed basis, not just when a software engineer declares a bug has been fixed.
Very strict controls need to be in place to allow/deny a software/hardware update to a driverless system.
I don't want my car to be hacked and used as a killer weapon.
I can imagine some lawmaker somewhere declaring a halt to driverless cars after this accident.
I have already several articles suggesting that this should not be done because only more and more refinement of such a complex product will cause it to become viable. Also even with a few bugs, driverless cars are possibly already less accident-prone than humans.
As a software developer, I naturally side with continuing development.
Looking at the FAA gives a good model on how to proceed.
When an airplane crashes, the FAA sometimes grounds all models of that plane until the cause of the crash is determined and, if it was a technology error, will not allow the planes to fly again until the problem is satisfactorily resolved.
That would appear to be a measured response to this type of problem.
Don't halt all development. Don't proceed, ignoring the death(s).
Prohibit the specific driverless system from using the public roads until the problem is determined and an acceptable fix is made.
Just as cars have model years that receive approval, so should specific versions of driverless systems.
Then we can have official patches deployed on an as-needed basis, not just when a software engineer declares a bug has been fixed.
Very strict controls need to be in place to allow/deny a software/hardware update to a driverless system.
I don't want my car to be hacked and used as a killer weapon.
Here are some good practices for developers:
1. When a bug is reported in a group project, there are 2 types of people.
1.1 Without any investigation, a developer declares that it isn't his/her problem.
1.2 A developer who assumes it might be his/her problem and starts investigating.
I certainly prefer the latter. This isn't about ego, it's about code doing its intended job.
2. Developing always creates bugs.
Prolific developers create lots of bugs.
Developers should not be judged on the number of bugs.
Instead, they should be judged on the ratio of bugs versus the amount of code they produced.
A corollary to the above is that good developers create a minimum of code for a given requirement. More code = more bugs.
Beware of developers who create complex solutions to not-so-complex problems.
3. If your ego is so fragile that you cannot handle making mistakes, you are in the wrong job.
As long as you are creating code, you will always make mistakes.
The key thing is to find techniques/procedures to avoid making the same mistake ever again.
4. Good developers assume something will go wrong in their code and put in more code to handle "unexpected" scenarios.
When something fails, it is really good to have it not fail badly.
5. Test, test and test again. Never assume anything works properly.
I have had code fail several times after many years in production.
It took all that time before the circumstances were sufficient to trigger the obscure bug.
This also ties in with point # 1 above, it is very easy after a few years of success to assume it is bug-free, when it isn't.
6. NEVER stop learning.
You can always improve.
7. With so many opportunities for self-education, learn to choose the most useful ones.
Learning the intricacies of one niche application will cause you to be good at that job, but what happens if that job ends?
A resume of widely-used skills is good for employment longevity.
8. MOST IMPORTANT.
Love what you do. Take pride in your work.
If you don't love what you do, find a new job.
You cannot pay someone to take pride in their work, but you can reward them for doing it.
The US tax code documents would seriously challenge Ms. Linda Watson.
Not because you cannot read the actual words, more because you cannot understand their meaning.
Same with most government documents from just about any government.
Instead of voting for a representative, why not use computers to allow any registered voter to directly vote on bills?
We needed representatives long ago when communications were poor.
Quality communications should make these corrupt representatives obsolete.
You could exercise your right to vote on bills that you had a strong opinion about and ignore others that you didn't care about.
I retired at 59 after almost 40 years of software development, culminating in 10 years being part of a great team of people developing an algorithmic high speed trading system on wall st. I max-ed out my 401k every year and retired fairly early with enough money to live frugally (relative to previous lifestyle).
I now live in a quiet waterfront home surrounded by farmland.
I go crabbing and have caught 1502 crabs so far this season.
I roast coffee as a loss-making hobby/business. I wrote some custom software for my coffee business that tracks everything and even is hooked via a thermocouple on my roaster to record roasting profiles.
I traded a horrible commute for the following stress-free early morning ritual. On warm mornings, I drink coffee on my dock and watch the wildlife. On cold mornings, I drink coffee in my outdoor hot tub and watch the wildlife.
I tell my kids about the tortoise and the hare: the hare (almost) never wins. Slow and steady rocks.
So this is what can happen when a programmer gets old. Persevere and good fortune will happen. Good luck to you all.
If someone alters a sign, it might trick a robot. Then again, it might trick a human too. So what's the difference?
Extrapolation of these results predicts that employees who work a 0 hour week will never take any sick days and will be extremely happy.
As a person in retirement, I can vouch for these results.
As someone who developed algorithmic and high frequency trading software, I fully agree that he is being singled out.
This guy was only doing what many of the large financial houses were and still are doing.
No pair of communications devices "has to share that information".
Data passed between my wireless mouse and my PC hopefully isn't sent to Logitech or Dell.
Data passed between my phone and my bluetooth speaker hopefully isn't sent to Bose or Verizon.
This data is sensitive enough that it should not be shared.
How can we be sure you are real and not some chatbot?
I suppose Hilary's private email server has saved her from being published by Wikileaks.
A previous poster suggested something incriminating would catapult Sanders into the DNC nomination spot.
If nothing actually incriminating is found, but something unfavorable is revealed, that would then help The Donald.
I'm glad to see iOS/2 is still alive. Then again, I suppose I am biased as I worked on OS/2 for IBM a very long time ago. I thought it looked very good versus the competition (Win3). Being a huge fan of open source, I have been using Linux for a very long time now. In fact I have always preferred Unix variants over anything else almost since I started working 45 years ago. It was a breath of fresh air versus IBM mainframes where I started.
Wouldn't it be nice (a naive thought) if we had a politician who:
1. We could trust
2. Put the country's best interest above his/her own
3. Wasn't in the pockets of the rich
Instead we have trump and clinton.
Maybe they should get married.
They both are the exact opposites of points 1 thru 3 above.
I wonder why people are feeling they are not represented?
It's not who you know that will necessarily get you a new job.
It's both plus having the ability to communicate in a reasonable manner.
When you are "experienced" and have quite a few years of development behind you, a decent developer will have built up a list of friends from previous or current jobs. Hopefully, these friends respect your ability to develop. When it comes time to obtain a new job, hitting up those friends is an invaluable resource. I have hired several colleagues from previous encounters in this manner. I have even hired the same guy twice. Each time I moved jobs, I pulled him in behind me. I have also been hired twice thru personal references myself.
Just think about it. Do you think an interview is much more than a crapshoot? You are trying to judge the suitability of a candidate based upon a few hours of interaction. Wouldn't you rather judge someone based upon their past performance of which you (or a friend you trust) are familiar, having previously worked with them?
I'm not saying that an old dog shouldn't learn new tricks. Far from it. It's every developer's responsibility to maintain their skill set. I am extolling the virtues of building a network of past/current colleagues who might be of help to you in the future, just as you might be of help to them.
So we are going to pay for a nuclear freight train to nowhere?
Couldn't we instead use the money to improve the existing rail network to encourage humans to use it?
The rail service in this country is such a joke that most people choose to pay between 3 and 4 dollars a gallon for gas, increasing pollution and funding the arms buildup in the middle east.
To meddle in something that is none of your business merely tends to give credibility to whatever you disagreed with in the first place.
“Never argue with an idiot. They will only bring you down to their level and beat you with experience.” - George Carlin.
“Never argue with a fool, onlookers may not be able to tell the difference.” - Mark Twain.
So if Iran or wherever wants to pass stupid edicts, just let it go ahead.
Have some respect for Iranians to recognize a horse's ass for what it is.
If a stupid government passes a sufficient number of dumb edicts that they eventually make themselves irrelevant.
Or maybe we should interfere and start another war which would surely help support a dumb regime (on both sides).
Typed www.brownlist.com URL into my browser and after a long wait got:
Server Error in '/' Application.
Runtime Error
Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons).
[...and some more]
Slashdotted?
Eat your hearts out.
I'm recently retired and loving it.
I'm currently building a kayak rack in my back yard without any deadlines.
Sometimes I just put down the tools and paddle off to check my crab pots.
At the start of every day I sit on my patio overlooking the water, drink my coffee and decide what (if anything) I will do for the rest of the day.
I wish I could have retired 40 years ago.
So long and thanks for the fish.
The day a company starts to innovate thru buying other corporations instead of creating stuff itself is the day it starts to die.
My wife connects waaaaay too many devices to a single power point by using multi-way adaptors.
Now she will be able to daisy chain various phones, laptops, portable speakers etc,.
Can you blow a USB fuse in this new standard?
Just send a predator and take out the Equadorian Embassy in London.
Sure, there will be some collateral damage.
Get the spin doctors to suggest it was Sweden that did it.