Regardless of which way you work you should try to look at the pieces that works well and improve the pieces that don't work well. Just nuking a whole company structure for a new process is never going to end well, it's like putting the building on fire because there's a few spiders in it.
Instead you should try to figure out why the spiders are there in the first place - maybe it's because they are the symptom of something worse in the house that you really don't want. Or the spiders are just opportunists themselves and will go away when they see that there's nothing to catch.
Processes shall always be built and improved slowly from the bottom to the top over time. Sometimes you need to re-arrange your organization, but it's a rare occurrence and done right you can do it step by step. The responsibility of the management is to know their organization and actually be present on the floor from time to time and talk with the people working. That will give a lot more than following the How Shit Happens procedure.
I see that on the high level in a very complex environment waterfall is probably giving the most structured way of working. I deliver a car to be tested on the road and get back the problems found.
On the low level where I work with software or hardware components then a flexible approach is better. But it requires that the whole team works in a coordinated way and that everyone knows what the reason is for what their part is developed for and what it shall interact with. A drawing of a door hinge drops down to the person making that hinge - if he can see where it's used and knows by hand the history of previous hinges made and what limits he have he can look at the drawing to see if previous problems have been addressed and then make a prototype - or even more than one prototype with suggested variations to address certain historical problems that can be tried out in test fittings. It can be subtle changes like increasing the length 10 mm to make it more stable. It will of course have to go back to the person making the drawing that the longer hinge is more stable so it won't cause other pieces to be moved that will come later.
An organization should firsthand try to avoid the situation "Jack of all trades, master of none" - everyone knows a little about everything but lacks complete specialists on any subject. Especially in large organizations. A newbie may not have much knowledge of how their part fits in, they may be fresh out of the university and have a very general and generic knowledge, so starting somewhere would give a good start, then build up competence over time and move around if they find that another part of the organization is better for them.
When you have a world of mixed maintenance and development the sprint idea is totally bullshit since it collects all work regardless of size into a "one size fits all" mentality and if it's a large job that has to be done that takes time then it's often postponed until there's time to do it and then it may be too late because that job is part of the OS platform that everyone uses in the platform and nobody knows why nothing works.
The result in the organization where I'm located has been "it's not my fucking problem" approach that has surfaced.
Agile is a method that works on the lower level in an organization with a locally homogeneous environment but on higher levels where it transits to a heterogeneous solution then it's applied in a way that would cause a welder to be able to code assembly and do electrical wiring as well. That turns a box of sharp tools into stone age rock bashing everywhere.
In reality I have broken it down to a/64 with a random 40 bit and also a random 8 bit subnet part. But in order to not expose what I have on my local net I still prepare to NAT it.
I understand that people think that NAT is bad, but it's not always bad since it also offers the ability to hide what you have from your ISP and some ISPs would like to control and know what you have in number of devices etc. It's after all a privacy issue to use NAT, not that it's technically better.
That's one problem - the content creators get so little for the videos they make that it's not really making much profit unless you put out viral videos on a regular basis. Many can just buy a cup of coffee for their effort.
If you make a living of making videos - then you have a problem of a different kind.
I agree - I don't care how the commands work under the cover as long as they have the names and syntax I expect since ages ago.
Most of the listed programs aren't really performance hogs anyway so there's not a huge reason to rewrite them unless there's some serious safety issues or stability issues that has to be taken care of.
Please don't generate time wasters trying to force people find new commands with new syntaxes doing what the old commands did fine. It's not worth it.
JSON is not entirely solving the serialization/deserialization problem, it's just making it in text format instead of binary format. It appeared after Java had created the serialization/deserialization and is even though it's better not the complete answer. It also adds a footprint penalty (bad for embedded) and performance penalty (bad for large scale solutions and embedded). So even though JSON is only ensuring that a numeric value isn't a character value suddenly it's only coming half-way and I expect that format to be compromised as well. XML actually also suffers from the same issue, but there you can in the XML Schema Definitions also place rules for what formats and ranges that are permitted, but it don't protect the integrity of the data in the channel between sender and receiver.
With large scale solutions I'm concerned about solutions where you process a massive amount of data in multiple computers where performance is the key. Java might not be the perfect solution for this, but sometimes it's actually used.
Then realize that the Java serialization/deserialization is very similar to actually just passing the data package of a C struct between two programs, so it's not really a surprise that it lacks some validation features and the data is assumed to be packed in a valid form when deserialized - which is good for performance but open to malicious injections. Adding an algorithm that signs/checks that the data actually was created by the same class/version as the deserializer would add overhead and increase security. If you look at RMI then you'd see the use of serializing/deserializing of objects.
But if you want to view the data you pass then JSON might be the alternative - but so is XML.
If you want to secure a channel from injection of incorrect data then you'd need a solution involving encryption and hashes to ensure the integrity. Installing signing certificates in the class that do the serialization/deserialization and keeping it up to date for every version would improve the security.
I was more thinking of the principle of uncertainty - the stronger you observe factors in economics the stronger you influence them. The factors may be strengthened or weakened, but the observer that sends the message isn't intentionally changing the flow of history - it's the accountants and economy specialists that sees that "oh - he got a Nobel Prize for that - then it must be true" while it is only true if you aren't aware of the mechanics around the actions.
Other people may also see and learn from it and try to profit from the results which in turn changes the game.
So from that perspective I think that the prize in Economics has done more harm than good.
Compared to having to write your own non-standard serialization/deserialization it's not bad. At the time when this was created there weren't much XML support either in Java and other languages.
A lot of computer languages and design paradigms have been created through history - some of them have been fine at the time, a few have survived, some have been overdue for replacement for decades but there are no way to migrate away from them.
If you want real pain in the ass - Cobol fixed size records where the signed data fields are very strange and not compatible with anything. May even depend on which compiler you use. Big-endian, little-endian and mixed word order are additional headaches that have been historical headaches. Even odd floating point number formats not using the regular IEEE notation because they were invented before that.
Revise Clinton to Nixon, even though Clinton did seed the latest crisis the long term problem was initiated already in the 70's, maybe even before.
One interesting thing is that the stagnation seems to coincide with the stare of The Sveriges Riksbank Prize in Economic Sciences in Memory of Alfred Nobel 1969. This tells me that the economic systems were heavily influenced by theories thrown up by people that focused on certain aspects while accountants and bankers used those theories as general rules and words of god without critical thinking.
I'd say that it's based even deeper - the concepts that have been designed by economic "experts" where mantras like "just in time", "warehousing of resources is bad" and ponzi-like retirement schemes have been built where the next generation has to pay for thd retirement of people born before them, even if they live longer. The retirement issue is one of the main problems for Greece. And that started already with people born in the 40's.
Subprime loans is not just part of the 2008 crisis, that was just the tip of an iceberg. Foreclosures are used without realizing that the banks ends up with the short end of the stick in way too many cases.
Healthcare only available for those that can afford it resulting in people not able to afford it to become an economic burden for society.
Cost of living in some areas has become so high that people need food stamps even if both family members have a job just to be able to raise their kids.
Education that's ridicuously expensive.
Inefficient and aging transport systems in cities where people waste many hours commuting - and that's eating up productivity. Add to it the misdirected idea that if it's getting harder for cars to get through people will use public transportation and the local trafgic situation will be safer - at the cost of lost man-hours. Now there's even talk about that the main transit roads in the cities damages the social life and causes particles impacting health - all while apartments are built just beside these transit roads.
City planning where areas of living is well distanced from areas of work forcing people to use cars or buses. And there's no point in moving since then the spouse will suffer the same problem.
Devices that are use and throw away - like mobile phones that are junk once the battery fails. And manufacturers that also maximize their profits on repairs. Cars is one example - the profit is maximized on the aftermarket side, the vehicles may even be sold at a loss. A lot of things also are getting more and more impossible to repair since they are built on specially designed parts - like batteries - that become impossible to get after a few years.
Taxes imposed on money not in circulation, like your house, that are raised just because you make improvements on the house with already taxed money. Or if you sell your house or apartment - then there are taxes too, which keeps people from moving even if they want, so old people sit there in a large house even though they could be fine in an apartment just because it's actually too expensive to move.
The value of a company is calculated on the short term profit of the company, not on the investment in future development. So companies can show short term good profit by firing their research&development teams, but effectively they are gutted and zombies. Internal invoicing schemes are also harmful - it's a misdirected idea on chasing costs that generates more cost. A lot of companies also look at projects to take care of the development, but in many cases those projects are set up in a way where you win each battle but lose the war.
Overly detailed specifications and solutions selected because they look good instead of being most efficient - or even fulfill the personal whim of a politician are also part of the problem. Like making a bridge that looks nice but is so low that shipping is constricted.
Overall - hate the bean counters that are short-sighted and only look at immediate profits as well as politicians looking to build monuments of how good they are.
Slashdot Mirror
Regardless of which way you work you should try to look at the pieces that works well and improve the pieces that don't work well. Just nuking a whole company structure for a new process is never going to end well, it's like putting the building on fire because there's a few spiders in it.
Instead you should try to figure out why the spiders are there in the first place - maybe it's because they are the symptom of something worse in the house that you really don't want. Or the spiders are just opportunists themselves and will go away when they see that there's nothing to catch.
Processes shall always be built and improved slowly from the bottom to the top over time. Sometimes you need to re-arrange your organization, but it's a rare occurrence and done right you can do it step by step. The responsibility of the management is to know their organization and actually be present on the floor from time to time and talk with the people working. That will give a lot more than following the How Shit Happens procedure.
Agile mind set for working is the same regardless of if you design software or hardware.
But Agile is useless when shoveling manure - there's only one way to do it and that's start shoveling.
I see that on the high level in a very complex environment waterfall is probably giving the most structured way of working. I deliver a car to be tested on the road and get back the problems found.
On the low level where I work with software or hardware components then a flexible approach is better. But it requires that the whole team works in a coordinated way and that everyone knows what the reason is for what their part is developed for and what it shall interact with. A drawing of a door hinge drops down to the person making that hinge - if he can see where it's used and knows by hand the history of previous hinges made and what limits he have he can look at the drawing to see if previous problems have been addressed and then make a prototype - or even more than one prototype with suggested variations to address certain historical problems that can be tried out in test fittings. It can be subtle changes like increasing the length 10 mm to make it more stable. It will of course have to go back to the person making the drawing that the longer hinge is more stable so it won't cause other pieces to be moved that will come later.
An organization should firsthand try to avoid the situation "Jack of all trades, master of none" - everyone knows a little about everything but lacks complete specialists on any subject. Especially in large organizations. A newbie may not have much knowledge of how their part fits in, they may be fresh out of the university and have a very general and generic knowledge, so starting somewhere would give a good start, then build up competence over time and move around if they find that another part of the organization is better for them.
When you have a world of mixed maintenance and development the sprint idea is totally bullshit since it collects all work regardless of size into a "one size fits all" mentality and if it's a large job that has to be done that takes time then it's often postponed until there's time to do it and then it may be too late because that job is part of the OS platform that everyone uses in the platform and nobody knows why nothing works.
The result in the organization where I'm located has been "it's not my fucking problem" approach that has surfaced.
Agile is a method that works on the lower level in an organization with a locally homogeneous environment but on higher levels where it transits to a heterogeneous solution then it's applied in a way that would cause a welder to be able to code assembly and do electrical wiring as well. That turns a box of sharp tools into stone age rock bashing everywhere.
In reality I have broken it down to a /64 with a random 40 bit and also a random 8 bit subnet part. But in order to not expose what I have on my local net I still prepare to NAT it.
I understand that people think that NAT is bad, but it's not always bad since it also offers the ability to hide what you have from your ISP and some ISPs would like to control and know what you have in number of devices etc. It's after all a privacy issue to use NAT, not that it's technically better.
That's probably the biggest problem with IPv6 - an attempt to solve more than what's really necessary with one blow.
And that's a good reason for NAT and private addresses for IPv6.
In my home net I run fd00::/8 and when the ISP finally get their thumb out of their behind I plan to do a NAT of that.
You can keep your IP address, 192.168.1.42
Neither do Telenor, and maybe it's time to spam the support of the various ISPs with request for IPv6.
You only need one controlled by the government - and you will have a three year waiting period for a subscription.
That's one problem - the content creators get so little for the videos they make that it's not really making much profit unless you put out viral videos on a regular basis. Many can just buy a cup of coffee for their effort.
If you make a living of making videos - then you have a problem of a different kind.
Because http wasn't invented when lp0 was created.
And why not present figures in metric values so that people in the rest of the world would be able to understand how big the issue is?
I agree - I don't care how the commands work under the cover as long as they have the names and syntax I expect since ages ago.
Most of the listed programs aren't really performance hogs anyway so there's not a huge reason to rewrite them unless there's some serious safety issues or stability issues that has to be taken care of.
Please don't generate time wasters trying to force people find new commands with new syntaxes doing what the old commands did fine. It's not worth it.
JSON is not entirely solving the serialization/deserialization problem, it's just making it in text format instead of binary format. It appeared after Java had created the serialization/deserialization and is even though it's better not the complete answer. It also adds a footprint penalty (bad for embedded) and performance penalty (bad for large scale solutions and embedded). So even though JSON is only ensuring that a numeric value isn't a character value suddenly it's only coming half-way and I expect that format to be compromised as well. XML actually also suffers from the same issue, but there you can in the XML Schema Definitions also place rules for what formats and ranges that are permitted, but it don't protect the integrity of the data in the channel between sender and receiver.
With large scale solutions I'm concerned about solutions where you process a massive amount of data in multiple computers where performance is the key. Java might not be the perfect solution for this, but sometimes it's actually used.
Then realize that the Java serialization/deserialization is very similar to actually just passing the data package of a C struct between two programs, so it's not really a surprise that it lacks some validation features and the data is assumed to be packed in a valid form when deserialized - which is good for performance but open to malicious injections. Adding an algorithm that signs/checks that the data actually was created by the same class/version as the deserializer would add overhead and increase security. If you look at RMI then you'd see the use of serializing/deserializing of objects.
But if you want to view the data you pass then JSON might be the alternative - but so is XML.
If you want to secure a channel from injection of incorrect data then you'd need a solution involving encryption and hashes to ensure the integrity. Installing signing certificates in the class that do the serialization/deserialization and keeping it up to date for every version would improve the security.
I was more thinking of the principle of uncertainty - the stronger you observe factors in economics the stronger you influence them. The factors may be strengthened or weakened, but the observer that sends the message isn't intentionally changing the flow of history - it's the accountants and economy specialists that sees that "oh - he got a Nobel Prize for that - then it must be true" while it is only true if you aren't aware of the mechanics around the actions.
Other people may also see and learn from it and try to profit from the results which in turn changes the game.
So from that perspective I think that the prize in Economics has done more harm than good.
Compared to having to write your own non-standard serialization/deserialization it's not bad. At the time when this was created there weren't much XML support either in Java and other languages.
A lot of computer languages and design paradigms have been created through history - some of them have been fine at the time, a few have survived, some have been overdue for replacement for decades but there are no way to migrate away from them.
If you want real pain in the ass - Cobol fixed size records where the signed data fields are very strange and not compatible with anything. May even depend on which compiler you use. Big-endian, little-endian and mixed word order are additional headaches that have been historical headaches. Even odd floating point number formats not using the regular IEEE notation because they were invented before that.
Make sure that campaigning is done in all states, not only swing states.
Revise Clinton to Nixon, even though Clinton did seed the latest crisis the long term problem was initiated already in the 70's, maybe even before.
One interesting thing is that the stagnation seems to coincide with the stare of The Sveriges Riksbank Prize in Economic Sciences in Memory of Alfred Nobel 1969. This tells me that the economic systems were heavily influenced by theories thrown up by people that focused on certain aspects while accountants and bankers used those theories as general rules and words of god without critical thinking.
Replace boomers with accountants and bankers.
Ux is a buzzword of this decade. The only ux I'd considermis HP-UX.
If you go to India you will see real inequality.
Depression is a beast of its own that usually won't be helped by a trip somewhere.
Some games are educational though - simulation games can actually reveal inconvenient truths when it comes to traffic planning.
I'd say that it's based even deeper - the concepts that have been designed by economic "experts" where mantras like "just in time", "warehousing of resources is bad" and ponzi-like retirement schemes have been built where the next generation has to pay for thd retirement of people born before them, even if they live longer. The retirement issue is one of the main problems for Greece. And that started already with people born in the 40's.
Subprime loans is not just part of the 2008 crisis, that was just the tip of an iceberg. Foreclosures are used without realizing that the banks ends up with the short end of the stick in way too many cases.
Healthcare only available for those that can afford it resulting in people not able to afford it to become an economic burden for society.
Cost of living in some areas has become so high that people need food stamps even if both family members have a job just to be able to raise their kids.
Education that's ridicuously expensive.
Inefficient and aging transport systems in cities where people waste many hours commuting - and that's eating up productivity. Add to it the misdirected idea that if it's getting harder for cars to get through people will use public transportation and the local trafgic situation will be safer - at the cost of lost man-hours. Now there's even talk about that the main transit roads in the cities damages the social life and causes particles impacting health - all while apartments are built just beside these transit roads.
City planning where areas of living is well distanced from areas of work forcing people to use cars or buses. And there's no point in moving since then the spouse will suffer the same problem.
Devices that are use and throw away - like mobile phones that are junk once the battery fails. And manufacturers that also maximize their profits on repairs. Cars is one example - the profit is maximized on the aftermarket side, the vehicles may even be sold at a loss. A lot of things also are getting more and more impossible to repair since they are built on specially designed parts - like batteries - that become impossible to get after a few years.
Taxes imposed on money not in circulation, like your house, that are raised just because you make improvements on the house with already taxed money. Or if you sell your house or apartment - then there are taxes too, which keeps people from moving even if they want, so old people sit there in a large house even though they could be fine in an apartment just because it's actually too expensive to move.
The value of a company is calculated on the short term profit of the company, not on the investment in future development. So companies can show short term good profit by firing their research&development teams, but effectively they are gutted and zombies. Internal invoicing schemes are also harmful - it's a misdirected idea on chasing costs that generates more cost. A lot of companies also look at projects to take care of the development, but in many cases those projects are set up in a way where you win each battle but lose the war.
Overly detailed specifications and solutions selected because they look good instead of being most efficient - or even fulfill the personal whim of a politician are also part of the problem. Like making a bridge that looks nice but is so low that shipping is constricted.
Overall - hate the bean counters that are short-sighted and only look at immediate profits as well as politicians looking to build monuments of how good they are.