Moving from VB.NET to C# is pretty easy. I made the switch ten years ago, but still do some VB.NET in maintenance mode. VB is OK, but there is almost no support any more (open source, tutorials, etc.) VB is not really easy to learn. Even VB script is not that easy. I would always recommend C# for people who want to live in the Microsoft environment. The tools are the best, and support is improving.
Agile is supposed to support making continuous changes to the requirements. When users and developers have something to look at and try out, requirements always change. Agile encourages responding to change requests as opportunities rather than problems.
There is nothing to stop Agile developers from deploying properly tested software.
I would have liked seeing how many developers like me work with laptops and dock to real keyboards and multiple monitors at the office.
I have a dell Inspiron laptop. At the office I have an old Microsoft ergonomic keyboard and two 1920x1200 Dell monitors.
I don't really think this report can be accurate, but I do have an observation about management style.
I have read studies that show that the more expensive an IT project is, the more likely it is to fail.
I think the "excess" failures are due to upper management "micromanagement". Usually, there is less upper management interference with small projects.
I think that this could demonstrate that upper management will sacrifice success for control. In my experience, most upper managers will get rid of anyone who can't be controlled, and they don't even seem to consider the effect on productivity.
The same thing is true with improving workers' (people who actually make things go) happiness. If worker happiness doesn't increase management control, upper management won't see the point.
I have recently worked for an organization that rewarded productivity, without regard for personal style. It was an amazing and unusual experience, and it made other management styles more obvious by contrast.
Slashdot Mirror
AI has been 20 years in the future since the 1960s.
Code.org trains peons to work in the sweatshop, not business leaders who exploit peons.
Moving from VB.NET to C# is pretty easy. I made the switch ten years ago, but still do some VB.NET in maintenance mode. VB is OK, but there is almost no support any more (open source, tutorials, etc.) VB is not really easy to learn. Even VB script is not that easy. I would always recommend C# for people who want to live in the Microsoft environment. The tools are the best, and support is improving.
Real ecosystems are constantly adjusting. It sounds as if the model is not sophisticated enough to deal with dynamic systems.
Agile is supposed to support making continuous changes to the requirements. When users and developers have something to look at and try out, requirements always change. Agile encourages responding to change requests as opportunities rather than problems. There is nothing to stop Agile developers from deploying properly tested software.
Project managers are usually hired by people who have no technical experience and no project experience. The result is about what you would expect.
I would have liked seeing how many developers like me work with laptops and dock to real keyboards and multiple monitors at the office. I have a dell Inspiron laptop. At the office I have an old Microsoft ergonomic keyboard and two 1920x1200 Dell monitors.
There are over 1 billion websites on the world wide web today.
I don't really think this report can be accurate, but I do have an observation about management style.
I have read studies that show that the more expensive an IT project is, the more likely it is to fail.
I think the "excess" failures are due to upper management "micromanagement". Usually, there is less upper management interference with small projects.
I think that this could demonstrate that upper management will sacrifice success for control. In my experience, most upper managers will get rid of anyone who can't be controlled, and they don't even seem to consider the effect on productivity.
The same thing is true with improving workers' (people who actually make things go) happiness. If worker happiness doesn't increase management control, upper management won't see the point.
I have recently worked for an organization that rewarded productivity, without regard for personal style. It was an amazing and unusual experience, and it made other management styles more obvious by contrast.