> However the market does't care for that. The market prefers short term gains over long term gains.

I agree with this. For example, Sun was sold for $5.6B in 2009. [1] While Skype was sold for $8.5B in 2011 [2].

Sun had Solaris, Java, SPARC, and MySQL. Skype was a chat tool.

Even today many popular databases find it hard to get billion-dollar valuations, while multiple Social Companies has done it.

The market doesn't care about core CS. It cares about monetary gains.

[1] https://en.wikipedia.org/wiki/Sun_acquisition_by_Oracle [2] https://en.wikipedia.org/wiki/Skype

Skype is / was not "a chat tool" - Skype was an opportunity to own the IP telephony space for both the business and consumer markets. That is potentially a huge revenue base, and fits neatly into a company like Microsoft that sits astride both.

Solaris, Java, SPARC and MySQL had all demonstrated that they weren't going to acquire major revenue streams, at least under the ownership of Sun. Their valuations reflect two different types of company, something the market is very able to understand.

Skype is basically the Type I error offsetting "passed on Google" style Type II errors. It's a crappy investment in retrospect, but it was a strong player in an obviously valuable market. IP telephony remains enormously valuable - Skype just didn't win the contest.

And ironically, a shortage of "core CS" was a major factor in that failure. Usable, high-fidelity, encrypted VOIP is an enormously difficult challenge, and after some early successes Skype failed to offer a quality product. Claiming the valuation as an argument that core CS doesn't matter looks pretty backwards to me.

The fact that it wasn't going to win the contest ought to have been obvious to anyone who actually used skype.

Their android app was a horror story. There desktop app was ho hum, chat reminded me of icq and it was completely obvious that the major players were going to be people who had hip social networks or were well positioned like say google with all android users and apple with all iphone users.

Skype was a tool to talk to grandma and I didn't forget the fact that they tied the number of people in a group chat to less than 10 if you didn't use an intel processor and resolution to buying a logitech camera.

Turns out even grandma has a facebook account now in fact she had one when lunatics decided it was a good idea to buy skype.

> Skype was a chat tool.

> The market doesn't care about core CS.

Yeah, implementing a peer-to-peer voice over IP with Skype's late 00s quality (which fell significantly since then) is not "core CS" and is just "plumbing", right.

Skype seems to have floundered not on lack of features, but on app stability and call quality. Honestly, it looks to me like an example of a technically-challenging product that failed by underperforming on core CS.

I'm not sure why it would be framed as low-difficulty, except that consumer-facing tools tend to get written off as simple.

The issue I have with this view is that unless you have people on your team with fundamental, "core CS" capability, creating a behemoth like Skype or Snap just isn't possible. Of course, there's a balance, and who knows, maybe it's Pareto with 80% of the team focused on engineering and 20% focused on math/CS/R&D.

The monetary gains the market sees are the direct result of clever math and CS, not bolt-on solutions that can be lifted from libraries on GitHub.

I don't agree with this view.

Most jobs working with software development is about creating business value. Either as an end-user product that your customers are going to use or with internal tooling that will help the business have more access to data, streamline processes, increase efficiency, etc.

This "no true Scotsman" approach to software development is actually quite funny after a while being a professional, it's a huge industry, there are terrible companies, there are terrible managers, product managers, etc., but there are also great ones. You can work for good ones if your current gig is mostly being pushed around by unreal expectations from your stakeholders.

The demand is not for short-term gains, how can you justify that it's going to take a year to build your perfectly architected software if the business really needs that done in 3 months and you assess it's quite doable if you decide on some constraints? Your job as a professional engineer is to be able to find ways to do your work as best as possible given constraints, to design something to be improved on over time, to communicate with stakeholders and, given your area of expertise (software), give valuable input to the business decision so they can be the best as possible at that moment.

Seeing software engineering as some grandiose goal by itself is quite wrong, software exists MOSTLY to fulfil business purposes.

It's not about "conforming", there is software that is fun to work, that are intellectual challenges by themselves but that really have no way to be justified on a business level.

This defensiveness against "business" is part of a mindset that should be broken among engineers, we should embrace we are part of a much larger process, not that we are the golden nugget and the top of the crop at a company. Our work is to enable others' work.

I actual agree with you. However when business claims to need it done in 3 months, do they? Lots of business software projects don't meet the deadline, they end up taking longer, not having complete feature and worse still ridden with bugs. They try to meet deadline, cut corners and end up with flaws. When the deadline is missed, more pressure is placed on developers and things get worse. Business tries to have their cake and eat it too. A business that exerts demand for a deadline, can't also demand for all features, cheap cost, and high quality. There are trade offs and these trade offs are often ill defined. The idea of lean software and agile is great and hopefully with time will solve this for the industry.

BTW, I'm now part of the business side now and a manager. If you give me time constraints, you don't get to give me feature demands, you can give me your prioritized feature list and I can tell you what we can deliver given all other constraints. If you demand all the features, then I take away the time constraint.

Agree with all of this -- I'd just like to add that I think there's a second order point here that doesn't get much discussion; technical debt is often considered as something that's always bad, but sometimes the correct decision is to trim "quality" (from your trifecta) and get something out to the market faster.

I think that the debt analogy is a sound one; if you are buried under credit card debt then you might not even be able to make the interest payments. But if you take on debt in a considered and thoughtful fashion, then you can achieve things you wouldn't otherwise be able to do (e.g. buy a house, in the debt analogy). I have found that the debt analogy is very useful for communicating these tradeoffs to the business stakeholders.

So sometimes it actually is reasonable for the stakeholders to request you to compress the timeline on a sequence of features, if there's an external deadline that must be hit; we just have to make sure we get buy-in to come back and repay our debts (preferably immediately after the deadline).

> "how can you build this to be most efficient and cheapest in the long run and lifetime of the product"

I couldn't answer this question accurately. I can't even give remotely accurate time estimates for projects larger than "build a CLI tool to do this one thing," much less give an informed estimate about the tool's TCO. I feel like I'm just floating down the river, incrementally improving upon the stuff that we've already built and that nothing we planned to accomplish ever is.

I'm sure lots of people here have executed their Grand Vision for a project. But I'm also certain many of us never have.

You are forgetting opportunity costs in besmirching "build fast" over optimising for TCO. If I can use the code to gain an immediate business advantage it is entirely possible that I'll take something in 3 months than 6, even if it costs more in the long term. The language, and negotiation, required is of the Engineer, not the Scientist - there is still optimisation going on.