Whether it is $1 or $0.10, it is non existent for young software companies. If I'm penniless (after real expenses), where will I get those 10 cents to pay the taxes?
And I'm not making this up. We are about to get cash flow neutral in our company, and this law will literally kill us and make 20 US citizens unemployed.
It is unjust. It is destructive. It actively impoverishes all of us. This is where they trot out the cold, detached assertion of Robespierre that one has to break a few eggs to make an omelet.
As far as I know, this law has been a thing for a couple of years now. How has your company been dealing with it so far? You say "this law WILL" but if it's already in effect, then it means that you would have already had to find a way to pay taxes for the last few years right?
Well, same as any other expense. You find a way to pay for it, or you go out of business. If the number is 10%; you need either 10% more revenue or 10% less costs.
As long as the same is held true about car designs that never went to production, drug design that were not deemed profitable etc.
Why pick on just software?
Yes, clearly the same reasoning applies to any copyright, patent, or trade secret (and we should stretch out the depreciation schedule to match the durations of those things. It follows that development of trade secrets would not be deductible. Perhaps a new category of escrowed expiring trade secrets could be created to make it deductible). We could all benefit from companies publishing research that didn't pan out, and it should come at little to no cost to them!
If we are being pedantic, sold or rented. I think the issue is on how the concept asset depreciation is applied blindly, as if dev salaries every year is the asset value every year. Unlike other asset classes, there is no easy to way value software beforehand, because you are not buying it from some market.
Today I am cash flow neutral at 5m revenue, but with this I'm paying taxes on 800k "profits", which don't exist anywhere but on paper. But I have to pay the taxes in real dollars.
This is going to sound silly but you paid 800k in profits, but now have 4 years of banked costs you can use to _reduce_ your profit margin.
So you pay taxes on 800k profits, but then each subsequent year you reduce you profit by 200k, even though you don't have 200k leaving the door.
If 1M eng salaries was your stable state, then after several years you're... going to have 1M in costs to subtract from your profit! The stable state is the same!
I'm not going to argue about the capex change being "good", I do think it's worth highlighting that for large enough companies you're now looking at a different flavor of tax flow. Amortizing your costs over 5-10 years is something people like doing for other costs after all.
It becomes a cashflow issue for startups. While the stable state is the same (not really the same, because of how companies evolve etc), cashflow issues in early days means $$$ from the VC money that I could've used to grow the company, now goes towards taxes for 5 years. That could be make or break for small companies.
If you have a pile of cash that you have no apparent use for, or can live without, yes, it makes no difference.
Models can be biased, but it doesn't seem like it should be a reason to get the answer wrong, right? Humans have biases too, but we don't get those simple questions wrong
I'm biased, but this is yet another thing my team has to build and maintain now.
I am not in the business of building and maintaining integrations, but trying to derive and surface signals that are useful to my business, from all the data (often crappy data) that's generated. Even just dumping data in a database is not sufficient, because it's not clean, not unified with other data, highly duplicative in many cases and so on.
I'm glad these options exist though, for teams that thrive on building everything themselves.
Totally understand - you want clean, unified data for business insights, not another integration tool to maintain. Sequor actually grew out of our Master Data Management (MDM) work where data cleaning and deduplication are core challenges. We focused on API integration for this release, but have mature data cleaning/deduplication components that we plan to open source as well. What specific data quality issues are you dealing with? Happy to share what we've learned from MDM projects and our data quality engine.
That's exactly where I landed too. We didn't need a modern data stack managed by a data team, where everything is coded with significant turnaround times. We ended up using an MDM (Syncari).
MDMs are unsexy and have a lot of baggage filled with legacy, expensive vendors. But the principles are sound, and more modern platforms have turned out to be pretty good.
"don't do it" is the right answer. Others have pointed it out as well, many large SaaS companies I worked with, have had apps owning their databases. Anyone else needs anything - use APIs (and ETL if you need everything)
It's definitely not the right answer. It's actually the completely wrong answer.
Services are slow, restrictive, and don't enjoy the benefits of an actual DBMS, like transactions. You also add additional dependencies and failure points.
This isn’t a discussion of whether you should use services or not, only what to do in the case where you do have separate services interacting with a schema. And, in this case, trying to maintain consistency with multiple apps accessing the DB directly can quickly turn into a nightmare. Better to maintain separate services interacting over some contract to insulate multiple codebases from the internals of each other.
> Better to maintain separate services interacting over some contract to insulate multiple codebases from the internals of each other.
All you've done is shifted the dependency and made extra work when schemas change. Now we have schema updates, _and_ service updates.
As I said, you give up transactions, performance, and flexibility. You also increase the workload, and increase failures. There is almost no good reason for what you're proposing.
I am not sure I understand. The context was multiple applications managing/accessing the same database. No matter how you slice it, a schema update is accompanied by application updates. If anything, in a service oriented approach, you can potentially isolate the impact by versioning APIs and writing compatibility logic in a single place.
No, it’s not obvious the DB changes because the team depending on that schema doesn’t necessarily talk to your team much, and you might not even know that team exists.
The same is true for API contracts but the culture of changing an API is much more understood as something that must be communicated and processes are more rehearsed.
> No, it’s not obvious the DB changes because the team depending on that schema doesn’t necessarily talk to your team much, and you might not even know that team exists.
Literally everything you just said applies to services and API contracts as well. You haven't solved anything.
> the culture of changing an API is much more understood as something that must be communicated and processes are more rehearsed
You're just making this up. There are thousands of incidents every day because someone changed an API without communicating to every stakeholder.
"Services are better than databases because service owners are better at communicating changes than database owners" isn't a very compelling argument.
I'd work to fix the communication problem before I adopted a terrible tech solution.
>> the culture of changing an API is much more understood as something that must be communicated and processes are more rehearsed
> You're just making this up. There are thousands of incidents every day because someone changed an API without communicating to every stakeholder.
What you wrote isn't a contradiction of what I wrote. I wrote "more understood" not "perfectly solved problem."
> "Services are better than databases because service owners are better at communicating changes than database owners" isn't a very compelling argument.
Except they are because the tooling is better. I can check calls to an API endpoint using the same tooling that I would for checking end user API calls. I can push out comms to use the new API, I can confirm calls go to 0 before deleting the old endpoint.
For checking that a table or column is being accessed before changing / deleting it? Fuck, I don't actually know how I'd orchestrate that. And once I've made that change (vs when I make an API change), well, I hope I got it 100% correct because reverting that change is harder.
It is more that services allow more backward compatibility than direct DB changes, because you can also code additional logic to maintain that.
Of course in a narrow case where all apps that need the same DB need to be upgraded/fixed in lockstep, maybe you can get away by directly updating the database. But more than 2 teams, it will quickly be a nightmare of conflicting priorities across teams, amount deployment coordination required.
"Oh you cannot change this schema right now because 3 other apps depend on it and they dont have time to make the necessary changes in their app to accommodate this right now, for the next 6 months"
Except if your schema changes in a way that forces your API contract to change, you have a big red alarm to tell you to investigate what’s using that contract and update it too.
When your apps connect to a DB schema, the change is silent. You just run ALTER TABLE and… whoops, you just brought down a service you didn’t know existed because the contract was implicit.
MCP is basically APIs V2 as far as I can see. It probably will evolve in its concrete specs, but useful and not niche, especially when they can be composed fairly trivially.
In that sense, it is probably the building block for the next user interface, which is conversational.
Maybe the mention of web 2.0 is triggering all negative responses here, but on it's own, it is useful and could disrupt (not MCP itself, but the overall field) how we interact with software and systems
And I'm not making this up. We are about to get cash flow neutral in our company, and this law will literally kill us and make 20 US citizens unemployed.