With the exception of OpenFOAM, all of these software are proprietary, largely non-interoperable, and expensive—like thousands to tens of thousands of dollars for the cheapest option with basic functionality kind of expensive; like I can never imagine opening my independent consultancy business because how expensive the basic tools are kind of expensive.
Outside of programming, this is the norm. The number of free and/or open-source tools available to a mechanical engineer or an electrical engineer are infinitesimally small and it is almost impossible to do a serious engineering project with only free tools.
Since this is quite lucrative for the companies making those tools, I can only imagine tech companies would be more than happy to lead us to a future where software engineering is similar in this regard to other engineering disciplines. Perhaps this is what happens when a field matures, and since software is maturing, it will become more and more like this as the time goes on.
>Since this is quite lucrative for the companies making those tools, I can only imagine tech companies would be more than happy to lead us to a future where software engineering is similar in this regard to other engineering disciplines. Perhaps this is what happens when a field matures, and since software is maturing, it will become more and more like this as the time goes on.
That's a really great insight. (Sr EE here.) I wonder sometimes about the fact that SW engineers are capable of making their own tools in a way that we are not. Do you think this helps to combat some of the super high pricing associated with their tooling?
For example: it'd be pretty hard for me as an EE to say "Fuck it! I'm fucking sick of Orcad! I'll just go write my own fucking Orcad!" (OK, well, easy to say. Hard to do. I've spent plenty of days cursing Orcad, but none building a suitable replacement.)
That's part of it. There's also the element that in many engineering fields, there is a floor on project pricing. Think Civil Engineering, Chemical Engineering, etc., most of those projects start at 6-figures, and often go into 7 or 8-figures. A per-engineer cost of $Xk/yr for tools is really not that much, in the scheme of things. I think you're seeing a similar increase with web designer tools. Adobe doesn't want you to think of a Creative Suite license as $500 or $1000, they want you to think of it as 1% of your employee's salary.
I can only speculate, since I am not a software engineer, but I think part of maturing is things get more complex and making things more difficult and expensive. Thirty years ago, someone could say "Fuck it! I'm fucking sick of Unix! I'll just go write my own fucking operating system!" and actually do it. Today, operating systems are so complex and large that this is not feasible anymore. Maybe you can write your own AWS replacement today, but would you able to write a replacement for AWS of 2050 in 2050?
It it one of those things that I would be happy to be proven wrong about, but as of now, I am not super optimistic that the current state of freedom of software engineering tools would continue indefinitely.
And you can write software on you spare time, and distribute it. Like it was done for Linux, gcc, git, and many other open source software. The other reason we have free software is because many software companies write their own tools and distribute them as Open Source because those are just tools, not what makes them money.
AWS on the other hand, is not just software but it's infrastructure. It's servers that are running, maintained, etc. There are already Open Source alternatives to AWS, that you can install on your servers and maintain, but it's a very different experience from using the AWS tools on Amazon's servers.
I agree. I think this is a great, succinct description of the underlying "why". It's a moat, to use PG's term for it.
I could make a better Altium. It's just that Altium has a few decades head start on me. XD
Actually software engineering had been like that for years in (distant) past. Most operating systems and compilers (that mattered for businesses) cost significant amounts. Not to mention access to computers.
It is said that Bill Gates' access to shared computers in his private high school [1] gave him advantage that very few people at that time could have had.
[1] https://www.cnbc.com/2018/05/24/bill-gates-got-what-he-neede...
I'm more comfortable talking about mechanical CAD, and in that space FreeCAD (while amazing for a free tool) doesn't come close to professional tools like Solidworks or Catia. Even for personal 3d printing projects it's really lacking, let alone for professional work.
My understanding (which may be wrong) is that FreeCAD just does drawing, if you want FEM then you go get some FEM software. That’s not FreeCAD being incomplete that’s good software design, kind of like the Visual studio vs vim/gcc/gdb/make/git/valgrind/cscope debate.
Yes, basically.
FreeCAD only does 3d modelling and 2d drawings, that's right. That's not what I "complain" about, this is normal, that's a CAD package. FEA is another software category.
But it's really lacking in modelling compared to professional tools like Solidworks.
I’m in the same boat as an EE, however some of these tool vendors will cut you a break as a consultant. The same PCB tool I pay $10k/seat at work I bought for $5k at home.
If I run a motorpool that is all Prius, then I'll want Prius mechanics.
Heck, you can still make a career on being an expert in IBM 360.
It's pretty common to go deep on a particular vendor's technology and make a career of that.
I could be super wrong but I'd expect a Java programmer to become useful on a C# project faster than I'd expect an AWS person to become useful building out other cloud infrastructure.
I think that is indeed wrong. The major clouds are all pretty similar in terms of the commodity IaaS services - VMs, disks, networks, load balancers etc., right up to things like managed Kubernetes clusters (AWS EKS, Google GKS, etc.) The basic correspondence between those various components is obvious, and the underlying infrastructure is the same - you still end up with servers with disks and TCP network access running whatever OS you chose. The situation gets even less different if you use something like Kubernetes, since your interaction with clusters largely relies on Kubernetes tooling instead of the cloud provider's.
Someone very familiar with AWS should easily be able to find corresponding services in e.g. Google Cloud - I know because I just went through that, having years of AWS experience as a software developer and architect, and now contracting with a company that uses Gcloud. There are differences, but prior knowledge of what to expect tends to make it easy to find what you need.
The only real exception is when you get to proprietary SaaS products, like AWS DynamoDB or Google BigQuery. But these are managed services which require virtually zero maintenance, so it's really the software developers who have to deal with those differences.
The problem with switching from something like Java to C# is that, even aside from the language syntax and semantics differences, which one can pick up fairly quickly, there's a huge ecosystem of libraries and tools that all changes, and the details matter much more - what collection of classes/functions/methods does a library have, what are their names, what do they do, which ones are better than which other ones, etc.
The time to get up to speed on all that is going to be greater no matter what, just because of the sheer volume of detail involved. Not that a Java programmer couldn't get up to basic speed on C# relatively quickly, but to reach expertise with it and not have to consult docs for many little things, i.e. to get efficient and effective at it, takes much longer. I've done that too - I spent nearly two years at a company that used C#, and can't consider myself an expert at all, unlike with Java.
For example, Spring for the backend with a Xamarin/WPF frontend.
You need the experience as an AWS, GCP or Azure expert.
Tbh if you are an expert in X and I need you for Y and Y is analogous to X and there is time allowed for ramp up, then it's all the same to me.
Maybe you don’t understand how much people spend on these services? If you’re spending a million dollars a month on AWS then it pays to have a few people who focus on AWS full time and know it intimately.
I really don’t think you need to let yourself get disturbed by this.
Strictly talking policies, there is a lot to know there. Gotchas abound. Things that don’t transfer at all outside their ecosystem and I assume vice versa to azure or etc.
Personally I wouldn't make knowing all Postgres's ins and outs the "pillar of my career" but some people do. I don't see how doing that with AWS is any different.
This is something you can do with any provider, the names are irrelevant.
Some features are lock in, but this lock in can be seen as tech debt prior to delivery.
Being able to architect cloud systems is just being able to architect distributed systems. Specializing in one isn't a huge problem.
For as long as I been working job adverts have been asking for vendor specific skills
Oracle vs SQL Visual C vs C SAP vs ,..
It can be risky, and in my experience skills are less important than general technical experience, as it’s easier to teach someone specific skills rather than teach them general aptitude.
Having said that, if you are moving to AWS and have no one with AWS experience in your organisation, then it may make sense to hire someone with relevant experience.
I'd rather hire someone who knows terraform and another cloud, than somebody who'll click on the GUI for my preferred cloud, and make excuses around not being able to follow process.
It's common enough for them no to be technical at all, such as a scrum master or project manager, it's also common enough for the first person on site (those working for really low remuneration and a lottery ticket) to just not be that good.
I'm afraid its a large part of the market here, but you're more exposed to the different parts of the market when you're contracting and thus moving around on a semi-regular basis.
But arguably if you are specialized in building internal tooling in AWS, the gap to design an effective HVT platform in AWS will be much harder to fill. Same thing goes if your specialization is more on the infra side of AWS or on the application development using paas.
It is SEO for consultants to effectively catch customers/agencies with specific platform needs: AWS Architect, SAP Developer, Tibco Developer, Wordpress Programmer...
And, yes, as dumb then as it is now.
On the other hand, enterprises don't care as much about vendor lock-in or portability as people on HN do. As a consultant working with many Fortune 500 enterprises, "we're an IBM shop" or "we're a Dell shop" or "we're a Windows shop" is more common than you might think. Enterprise companies want relationships, stability, and a business partner. They don't care about anything else. If they're an IBM shop, your default choice is IBM and any exceptions have to be run up through management. If they're a Windows shop, any request for Mac desktops or Linux servers has to be an exception as well. I've seen clients ditch million-dollar products they've used for years just because their digital transformation was AWS-only and that product didn't support running in AWS.
Enterprise companies WANT to be locked to one vendor, as it makes choices easier, makes the relationship easier, and provides stability to their IT operations. Cost and portability doesn't even factor into it. Lock-in is just a part of enterprise IT, has been for decades.
It feels strange that a community trying to start business has so little understanding from how B2B works.
An appliance is the ultimate lock-in and enterprise companies LOVE them.
That "if you have the tech talent..." qualifier is the big one, though. I see very few companies who recognize how to attract and retain that talent level. IMHO, out of the more than 200 companies I've consulted at or sold deeply enough into in the sales cycle to see enough of how their sausage gets made to form an opinion, probably no more than 1:100 do this. So we end up here, where most companies are content to hire well below that level, buy closed tech stacks, and then play support-tag while users sit unhappy. Plays well politically, but it's a mess for delivery service levels.
The reason enterprises can't hire that kind of talent is because they don't want to. The reason they can't retain that talent if they do accidentally hire it is because that kind of break-fix resolution
1) doesn't happen that often so the people get bored
2) is frowned upon by management because those people have actual jobs to do
and
3) is the entire reason they pay a support contract to their vendor
And $50k/yr in support costs is a lot cheaper than hiring the world's best DBA, world's best Linux resource, world's best Java programmer, world's best infosec analyst, world's best architect, world's best SAP resource, the list goes on and on.
The job of enterprise IT isn't to be the best at anything, it's to be stable and predictable.
Even Linux's adoption was more with not paying UNIX licenses than caring about any kind of openness.
Edit: I do understand why it can be lucrative to have expertise with a specific cloud provider. It's just the status quo of these services being their own unique silos that disturbs me: I would personally be wary of making "ability to effectively use Amazon's servers" a pillar of my career.