mscuwa

> However, the "asset" associated with software development seems pretty uniquely hard to transfer

Isn't it what's happening when a company gets acquired? Buyer pays for a software and a team (more for the latter usually, including business process as a whole), not for laptops or servers. It's not "equal" to salaries but you can't create the former without the latter. So in a sense when you pay salaries your create the above-mentioned "asset".

3. Agree, but this applies to assets depreciation too, how software is different?

I understand the rest and I'm not saying it's a good law. It's just not as bad as in the example with $1,000,000 above as IMO most companies won't be in that position, especially newly founded startups. The worst part is that it happens without a ramp up and with high interest rates.

If we are considering a stable company the only problem is that you expensed more since 2017 than you would have normally done, i.e. you effectively paid less taxes over 5 years. Now you need to catch up. I admit it's not fun, especially if everybody expects it won't happen, but overall it's the same tax.

    1,000,000 Revenue
  - 1,000,000 Salary expense
  -----------
            0 Profit

We are talking about an extremely lucky company if it's the first year. How many startups are able to get revenue equal to salary expenses in the first year? While they might exists, it's not very common. For all others and if it's not the first year you already have losses carried forward which will offset those 800,000 (since you didn't amortize them in the previous years, right?), so in your example if it's the first year you get any revenue you would have (years since founding) * $1,000,000 in losses. What do I miss here?

How you raise money doesn't make a difference. What matters is how fast you can utilize your "engineering assets". More often than not startups don't sell anything (let's say "anything" is > 20% of developers' cost) in the first year, or even in the first 3 years. So for them it's not a problem, you simply carry forward losses until you start getting revenue, and at that point you have enough losses to offset those 80%. It doesn't work for companies which are lucky enough to make substantial (comparable to the salary) sales in the first year. It's like Ford built a new factory, made 600,000 F-150 and sold them and the factory is basically gone in one year, there is nothing left. Doesn't happen with real factories though and usually doesn't happen with startups, but there might be exceptions.

> If you're not careful (or if you're trying to be clever), you can insert a String into an object that had been declared to be a List<Integer>

It's less about type erasure and more about missing covariance/contravariance in Java generics. Scala also has type erasure in generics (same JVM), but won't allow that (unless you explicitly upcast). HM doesn't recognize inheritance, so it's in a completely different category.

Expanding recruitment won't be racist by itself, no. But going beyond what company is doing now to hire more _black_ devs would be (they didn't ask where to recruit people, so they probably have enough candidates, the question was "where to recruit black devs if we don't have any black candidates").

So what you are suggesting is to go beyond normal company business to recruit black developers? I.e. to give black developers an advantage over all others. That's a textbook definition of a racism, don't you think?

My point was it's not becoming more buoyant, i.e. lift can only drop when it ascends. I wouldn't argue that it can burst, but it depends on material. As an edge case it won't go to the Moon as lift will be 0 in the vacuum. So unless there is a limit on balloon size the lift will be constant, otherwise it will drop during ascend.

Are you sure about positive feedback? Balloon does expand, but air outside becomes thinner, so buoyancy will actually stay constant until the walls are completely unfold, and then drop as gas inside will expand less than necessary to maintain buoyancy.

Create A+B integration branch, then merge in both directions, A -> A+B then A+B -> A (to pick up changes from B). Integration branch can be tested and merged to master later instead of individual branches A and B. It's not that complex as it sounds.