Any experience can alter your perception of reality, it doens't change reality. That doesn't mean it can't be a problem that needs to be addressed. It can also be a benefit and help people experience situations that would be dangerous to experience in real life so they get the skills to deal with them without being in danger. Think airline pilots practicing airplane failures in a simulator. The professional airplane simulators are so detailed, it really looks and feels like being in a plane.
I agree that this is needed. It doesn't stop the person requesting the feature from asking for a meeting to explain why and just whining that they need it the whole time and saying they shouldn't have pay anything to get it addressed right now.
Having in the person taking these meetings for a software vendor, it can get really toxic quickly and I never had more than 1 meeting a quarter with really toxic people and they were at least paying for the product and maintenance so hearing them out was part of the job. It unfortunate to get to the point where you view customer requests as antagonistic, but I can see how it happens. Some people really feel entitled, and some have a job to do and limited resources or control to do it in.
Great article, I have I seen this situation too many times to count. It isn't just consultants that generate haunted graveyards. Any person will skills more advanced than their peers will do so. To make matters worse it isn't just the peers you have right now but the peers you will have in the future who you don't currently know and can't predict their skill level.
While the solutions you list can help, it will not solve the haunted graveyard problem, just ask all of the companies with Cobol programs in production.
Reminds me of a dev team I once encountered where they stated they wanted to be expert C programmers and that they didn't understand pointers, so they avoided them.
Interesting article and I have observed all of the situation described in it.
I would like to point out that when agile, and even Scrum to some degree, was introduced it was a way for people creating software to take back control of a runaway process that prevented team from doing their best work. It was a grassroots movement championed by people invested in finding better ways to create software that were less stressful and more successful.
Most of the issues in the article were coopted in Scrum to take control of software creating back from the teams. Whatever replaces Scrum, and agile, will need to learn from the mistakes and compromises of Scrum or it will suffer the same fate as Scrum and become a tool to force teams into a delivery model that gives managers and executives more control while reducing their accountability.
Makes sense for desktop software, less so for webapps and web services. I agree with the point that developers should profile their apps and for some apps having a bad computer is an implicit way of doing that. It doesn't mean it is a good strategy for everyone.
It makes even more sense for webapps, with the bloated frameworks, non native performance single threaded performance, network access overhead and bloated json parsing everywhere.
Force that dev to try out his app with cpu and network throttling to simulate a normal mobile phone user on a shitty mobile network and he'll soon reconsider fetching 10mb of javascript bundles and rerendering the entire page every time the mouse moves.
This, plus the best machines tend to come with high quality monitors, and testing your web apps a using lower resolution can expose all kinds of UI and accessibility gotchas.
They had that rule, every 24-hour room checks, for a few years after the Mandalay Bay mass shooting in 2017. Since Covid they removed that rule and don't do the room checks every 24 hours, unless, I guess, they really want to do it.
Room service counted as a room check so security only did it if you refused room service.
2 features here really mean 2 development tasks however a task is defined for your team. The idea is to have one to work on while the other is in the background (maybe being worked on by your subscience) and to take a new one once one is done, even if it isn't worked on immediately.
The main goal of work in progress limits to get work to done rather than starting new work (that doesn't get to done).
Ideally in Scrum your sprint commitment is a work in progress limit but in practice it isn't treated as such for reasons. Kanban can allow expedited issues to address an "emergency" issue but even that has a WIP of 1 so emergencies have to be prioritized.
TDD is a design technique you can apply to low level or tactical coding design. Strongly typed isn't the same as a knowing and testing your inputs and outputs based on a plan or design of methods or functions. Sure, strongly typed can make that easier but it isn't guarantee it.
Testing after the fact usually means your tests a designed based on the code and not on what the code should do. Sometimes their little difference between the two, sometimes there is a large difference.
In my experience writing tests first is a slow down to speed up technique where the code is easier to write and maintain because it is tested and has built in regression testing.
Only in that the growth of cloud migrations might slow. The cloud is a great option for a lot of workloads and companies. Cloud native applications and services can be cost effective. Lift and shift is the most expensive way to go and can end up costing more than on-premise.
