lasereyes136

I met Vint twice where I spent about an hour each time talking to him in a group. It was years apart and he spoke about the social changes the Internet was bringing about. Always well spoken and thoughtful. It was impressive and I really appreciated was he had to say.

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.

No, it doesn't have to be a meeting. It can be any method communication.

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.

I told them it was hard to become a C expert without understanding and using pointers and they didn't like that answer. https://daedtech.com/how-developers-stop-learning-rise-of-th...

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.

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.

I see your point but disagree. Sun was the last holdout of the propriety Unix vendors to support Linux because they had underpriced the other Unix vendors like Linux was underpricing them. Sun's whole idea was to create cheap Unix workstations by using commodity parts and having a low-cost Operating System in SunOS and then Solaris.

Becoming a Nasdaq-100 company is a trailing indicator of going mainstream. By 2005 RedHat and Enterprise Linux had won, and Sun had about 5 years before Oracle purchased them.

OpenStack is great if you want to manage your own data center and some companies should do that. It is a cost/benefit analysis that some will make on the side of doing their own thing.

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.

Linux was a corporate-level operating system as far back as the mid-90s. It was the late 90s when it started getting enterprise software for example https://en.wikipedia.org/wiki/Oracle_Database released Oracle 8 was released for Linux in 1997.

> Companies are not going to entrust their business to a black box that sometimes says no.

Companies entrust their business to a black box that sometimes says no now. AI will not change that, and I agree it will get worse.

It is the irony of automation that some people still need the skills, knowledge, and abilities even more to fix problems that the automation can't fix. https://en.wikipedia.org/wiki/Ironies_of_Automation

Starbucks has grown to the point where it can't grow more, at least in the USA. So it has to raise prices to continue to "grow" revenue. I stopped going to Starbucks on a regular basis because the coffee is just fine so I prefer to go to local coffee shops where there is a chance the coffee will be good or excellent.

That said, I will still go to Starbucks while traveling because the stores are everywhere, and I will get a consistent quality drink. So I am not anti-Starbucks but increased prices without an increase in drink quality limits my desire to go there.

> just because insurance says its "totaled" doesn't mean it isnt fixable and safe to drive.

"Totaled" to an insurance company means they think the cost of repair at their contracted rates is more than the cost of paying out the "value" of the car. It is a business assessment, not an assessment of the vehicle.

All work has a cost including documentation. You either make updated documentation an explicit work item or it will, at best, get done ad hoc, at worst, it will not be done. If you allow urgency of code requests to bypass a documentation requirement expect documentation to fall behind. If you expect the team to create documentation without explicit time to do so, expect it to not get done.

It is either a priority to do with time set aside to do it or it isn't, and you get what you get. Even a time-box, best effort documentation effort is going to have a better result than "hoping" it gets done and making it a lower priority.

I prefer the set of trade-offs in shopping at Costco vs. a lot of other places. I also prefer the trade-off of getting stuff quickly without leaving home when buying from Amazon. I can see why some people would prefer other trade-offs, that doesn't make Costco worst or better, just a set of trade-offs I can live with.

I think part of the point of the article is that LLMs don't lie because they are designed to just give you the next work based on making a credible sounding sentence or sequence of sentences. Expecting it to do more is an expectations problem based on the hype around GenAI.

I don't think we have the correct word for what LLMs do but lie and hallucinations are not really correct.

Ask a tax lawyer.

My understanding, which is not legal or tax advice, is that, as a private person, you pay taxes in the state you have your primary residence in. There are a lot of rules around what it means to have a primary residence, so you need to check those.

> “Limit WIP” is a well-known recommendation in agile circles. It’s great except for the situations where it doesn’t work, eg. you have multiple customers with must-do features, you have support commitments and bugs to fix, your work doesn’t cleanly divide into [team size] pieces, etc.

This is exactly where you want to limit work in progress and have your management or leadership earn the big bucks by managing your multiple customers with must-do features expectations.

The way you get work to done is to focus on getting it done, not adding more work. Limited work in progress doesn't mean they can't be parallel efforts and most teams do that. It means that we figure out how much the team can do at once before it slows work delivery down and stick to that. Nothing is exact so some leeway is expected.

Kanban does have the possibility of expediting bug fixes or other work disrupting priorities, but it does mean that other work is done later and that needs to be managed by leadership with your customers and stakeholders.

> People who have worked in the second type of environment (deadlines are real and have consequences) become quite good at estimating and managing progress toward deadlines without crunch mode at the end. They become good at communicating issues with deadlines far in advance to avoid surprises.

So, incentives matter - shocking, just shocking.

Or maybe the take away is that is there is no incentive, someone made it up and it doesn't matter.

That is weird, people taking a body of work out of context to advance their agenda.

I see we worked at the same place.

True story, I was around in the 1990s so I was aware of those practices. Really advanced people would have a scheduled job running every hour (or on some basis) to keep an old copy just in case it was needed, usually a zip or tar file. So, a really crude versioning system.

Fast forward to 2008 and I am working on a project where we had an older person working on the project that would do this, use a scheduler to create a zip version. The younger guys I worked with said it was a crazy system and didn't understand why someone would do that. I told him it was an advanced practice just 10 years ago. Basically, people did a lot of stuff that would seem crazy now given the tools we have now.

History teaches us that "business people" want to "reduce cost" so they will try anything to achieve cost savings. They see the people in the software creation process as necessary evils, or uh, costs, instead of integral to the process of translating vague, usually English, business words into software.

4GLs (Visual Basic, Delphi) and Low/No Code are promised as ways to have "business analysts" or "citizen developers", i.e. lower cost resources, do the work. To be honest this is successful enough to keep selling the idea and products for a period of time. In reality most of the successful work in these areas are done by developers or people that could be developers.

Code generation by LLM is the same thing. Yes, it has value. In the hands of a motivated software developer it will do great things. In the hands of someone that wants to take a short cut because "lower cost" it will fail way more often than it will succeed.

That said, AI and code generation are here to stay and software developers should get used to using them.

The point isn't that disruption can't happen, as we know it can. The point is that is can take a lot to dislodge an entrenched product, usually more than just new features, especially rarely used new features.

As pointed out, the main driver is switching cost. Going to HN has low switching cost. Moving off Oracle has very high switching cost. I know of companies that have been actively trying to move off mainframes for 30+ years and are still paying switching costs.

The mall kiosk where you can get a broken iPhone screen replaced is a business model predicated on right to repair.

Independent computer repair people are as well but I am not sure how may of those are left.

Build software isn't like building physical things. Software and physical things operate under different constraints. All analogies are are wrong or off but some are insightful.

The insight here is that people expect things not based on reality but on desire. With architecture there is a process to give the architect leverage to say no to ridiculous requests, architects need to be licensed, which is hard to get.

We have no such leverage in IT so we get threatened with "do it or I will find someone that will" and businesses are always trying to find that cheaper someone or group of people that will do the work they have in their head on time, for a cheap budget, and without asking a lot of questions like "why do you think I would know something you didn't say or write down".