I travelled for some time to Finland for work, and almost all the office buildings there was chock full of large windows so as to soak in as much sunlight as possible during the limited daylight in winter. Also most had awnings over the windows as well to guard against the never ending sunlight in summer...
I did like the building layout where all the offices were on the outside walls and the lab space was in the center. There was also a lot more habit of taking the laptop to the lab space to do serious work rather than sitting in the office all day.
My cube is next to a window. It's by a parking lot, but sitting down all I see green tree leaves and blue sky and no cars or asphalt. This is more than I see at home to be honest. Also the lighting is a soft LED that is much nicer than flourescents. It was a big boost to mood going from a cubicle near the center of an aging building with crappy carpets to a refurbished building with sunlight.
"Datacenter:" means a lot of things. When I hear it I think of something giant to support thousands of customers, as opposed to the servers supporting just internal email and documents and backups.
The problem comes from the desire to more rapidly load and unload a ship to increase profits. Having partitions or baffles will slow this process down. Like anything to do with profits, the risks are evaluated and considered acceptable by those in charge.
I believe this bit. My mother refused to believe that the guy who was trying to get her money and the guy who offered her free IT services were the same guy. After long explanation I asked "you don't believe me do you", and she said in a quiet voice, "no".
Don't forget the senators who will fight tooth and nail to keep that project alive and well if it's in their district. The natural forces that would otherwise cause a badly thought out and badly managed project to fail do not operate in this domain.
Being dependent upon "the cloud" is not a good thing, and yet so many companies are throwing out their brains and signing up in the hope to reduce costs. The company that recently purchased my previous employer is in whole hog for Microsoft, Microsoft 360, Microsoft cloud, and anything with the word Microsoft attached, most of it all online only. To read some corporate announcements I have to log into a third party site which just seems absurd to me. When the cloud servers eventually get their inevitable downtime, I predict a lot of hand wringing.
I haven't seen this level of slavish devotion to a single vendor since the IBM administration.
But I've said in other comments, not everything can be broken down into units where you can show that it works without causing additional effort. Granted I'm not at a typical Agile place. We have solid deadlines, a waterfall overseeing everything (in order to meet the deadline and keep all disparate teams lined up), we're embedded development so there are requirements across different departments, we have multiple ongoing projects plus maintenance of past products, and not enough people.
And this is why it's not really working. The guys at the bottom are driving Agile, and they really have no influence over the entire product lifecycle, except maybe at tiny startups.
Short of people, short of people who know the ins and outs of how things were done, and product managers who always think they're project is the most important. So big all hands meeting where the executive VP says "don't work on lower priority projects" and then in the afternoon a product manager shows up with a new pet project, bypassing the managers who say no and going straight to the developer. Oh well...
It also helps of those team members are well trained in all aspects of the project. This way any member can work on any story. In reality though it's obvious that this never works except on the simplest of projects. You want your security expert to design the security stuff, you want your gui expert to work on the gui, you want your network expert to work on the protocols, etc. If you're lucky enough to have multiple members for each specialty then congratulations you are not a typical company.
We never do full day sprint planning. But we do have project planning. There's already enough meeting overload with with everyone on five projects and three sprints (yes, we're doing it wrong but we can't hire more). So with the project plan we know what upcoming stories need to get done for several months out, and we get a lot of "I'm continuing my ongoing task so I'll add a new story for the next sprint" stuff.
I often felt that putting points on stories would be the same as committing myself to a promise. Thus if I was behind, I felt that I had to work longer to keep my promise. So Agile was making me work longer. Over time I learned to do more sandbagging so that I was never over-committing.
After all the goal is NOT to do Agile, the goal is always to build the product. So if Agile is getting in the way, then be dextrous and sidestep it.
Most people do exactly the same thing with waterfall. There is continuous reporting of status in every well managed project regardless of the process. Your manager wants to know how you're doing, the director wants to know how well the teams are doing, the product manager wants to know how things are going, the project manager wants to know how different organizations are syncing up (boards arrive next week, are you ready for them), and so forth.
And it takes more than 3 sprints usually to even get some initial planning done (assuming your agile process includes planning).
But a task in Agile is supposed to involve being done with it and being able to demo it. Most places don't follow Agile that rigidly, but it is what you're supposed to do. So at some point you can't subdivide further because what you have is unfinished work that can't be demoed except by doing even more work. There is overhead to each and every story and if the stories are too short you end up doing more overhead than actual work (ironically this is the paradise for many programmers I've met).
Ie, one line of code is NOT a task. One function is not a task.
Slashdot Mirror
I travelled for some time to Finland for work, and almost all the office buildings there was chock full of large windows so as to soak in as much sunlight as possible during the limited daylight in winter. Also most had awnings over the windows as well to guard against the never ending sunlight in summer...
I did like the building layout where all the offices were on the outside walls and the lab space was in the center. There was also a lot more habit of taking the laptop to the lab space to do serious work rather than sitting in the office all day.
Naw, my cubicle is nicer than my home office. The cubicle has air conditioning and someone who vacuums every now and then.
My cube is next to a window. It's by a parking lot, but sitting down all I see green tree leaves and blue sky and no cars or asphalt. This is more than I see at home to be honest. Also the lighting is a soft LED that is much nicer than flourescents. It was a big boost to mood going from a cubicle near the center of an aging building with crappy carpets to a refurbished building with sunlight.
"Datacenter:" means a lot of things. When I hear it I think of something giant to support thousands of customers, as opposed to the servers supporting just internal email and documents and backups.
I dunno, I work on IoT censors all day.
That's what "overrated" is for.
Also the other golden rule of slashdot, "if you disagree with me you are a SJW virtue signalling libtard."
They're not in containers. They solids are directly into the hold, so it acts like a giant dump truck filled with sand.
The problem comes from the desire to more rapidly load and unload a ship to increase profits. Having partitions or baffles will slow this process down. Like anything to do with profits, the risks are evaluated and considered acceptable by those in charge.
I have been tempted to say that these fake IT scams all come from Hillary, just so my mother would take them more seriously.
I believe this bit. My mother refused to believe that the guy who was trying to get her money and the guy who offered her free IT services were the same guy. After long explanation I asked "you don't believe me do you", and she said in a quiet voice, "no".
Cheaper maybe with two drones that you cycle though.
Don't forget the senators who will fight tooth and nail to keep that project alive and well if it's in their district. The natural forces that would otherwise cause a badly thought out and badly managed project to fail do not operate in this domain.
Being dependent upon "the cloud" is not a good thing, and yet so many companies are throwing out their brains and signing up in the hope to reduce costs. The company that recently purchased my previous employer is in whole hog for Microsoft, Microsoft 360, Microsoft cloud, and anything with the word Microsoft attached, most of it all online only. To read some corporate announcements I have to log into a third party site which just seems absurd to me. When the cloud servers eventually get their inevitable downtime, I predict a lot of hand wringing.
I haven't seen this level of slavish devotion to a single vendor since the IBM administration.
Well, going longer than 2 weeks will inevitably have someone tell us we're doing it wrong :-)
But I've said in other comments, not everything can be broken down into units where you can show that it works without causing additional effort. Granted I'm not at a typical Agile place. We have solid deadlines, a waterfall overseeing everything (in order to meet the deadline and keep all disparate teams lined up), we're embedded development so there are requirements across different departments, we have multiple ongoing projects plus maintenance of past products, and not enough people.
And this is why it's not really working. The guys at the bottom are driving Agile, and they really have no influence over the entire product lifecycle, except maybe at tiny startups.
Short of people, short of people who know the ins and outs of how things were done, and product managers who always think they're project is the most important. So big all hands meeting where the executive VP says "don't work on lower priority projects" and then in the afternoon a product manager shows up with a new pet project, bypassing the managers who say no and going straight to the developer. Oh well...
Problem is, I can never work on only one thing. It makes it hard to judge if I even get a chance to work on the story at all during the sprint.
But what if it takes longer than a sprint to write it?
It also helps of those team members are well trained in all aspects of the project. This way any member can work on any story. In reality though it's obvious that this never works except on the simplest of projects. You want your security expert to design the security stuff, you want your gui expert to work on the gui, you want your network expert to work on the protocols, etc. If you're lucky enough to have multiple members for each specialty then congratulations you are not a typical company.
We never do full day sprint planning. But we do have project planning. There's already enough meeting overload with with everyone on five projects and three sprints (yes, we're doing it wrong but we can't hire more). So with the project plan we know what upcoming stories need to get done for several months out, and we get a lot of "I'm continuing my ongoing task so I'll add a new story for the next sprint" stuff.
I often felt that putting points on stories would be the same as committing myself to a promise. Thus if I was behind, I felt that I had to work longer to keep my promise. So Agile was making me work longer. Over time I learned to do more sandbagging so that I was never over-committing.
After all the goal is NOT to do Agile, the goal is always to build the product. So if Agile is getting in the way, then be dextrous and sidestep it.
Most people do exactly the same thing with waterfall. There is continuous reporting of status in every well managed project regardless of the process. Your manager wants to know how you're doing, the director wants to know how well the teams are doing, the product manager wants to know how things are going, the project manager wants to know how different organizations are syncing up (boards arrive next week, are you ready for them), and so forth.
And it takes more than 3 sprints usually to even get some initial planning done (assuming your agile process includes planning).
But a task in Agile is supposed to involve being done with it and being able to demo it. Most places don't follow Agile that rigidly, but it is what you're supposed to do. So at some point you can't subdivide further because what you have is unfinished work that can't be demoed except by doing even more work. There is overhead to each and every story and if the stories are too short you end up doing more overhead than actual work (ironically this is the paradise for many programmers I've met).
Ie, one line of code is NOT a task. One function is not a task.