For product people probably (hopefully) no, but for tech people? Where do I even start? :D
It’s kind of makes sense that for developers the only thing matter is the tech stack, that’s what we are hired for, but making it part of the culture to care about the customers and product needs effort IMO.
When we deal a new feature, the first thing I see are the features required, the second thing I see is how it will be accomplished in the tech stack.
For us, while we eventually have customers outside of the company - the product seems to be made for the internal groups. They have direct contact with external consumers (business users).
I can see how that would make it harder to see the external customer.
But your stack is unlikely to ever be the “main character” your customers rave about
Weeeell… In the early days, whatever you can put together and sell is fine. Later on though, if the company can manage to stick around, the tech stack will matter because it will determine how easy/hard it is to scale your engineering org. Tech stack also affects things like how easy/hard it is to accrue tech debt.
So, of course it does matter, but in most cases the company either doesn’t make it that far or get large enough for it to matter.
Tech stack also affects things like how easy/hard it is to accrue tech debt.
Does it, really? I would imagine this to be one of those things that might be hypothetically true in a vacuum, but in reality the effect is overwhelmed by more important factors such as engineering skill, communication, culture, economics, management style, etc.
What sort of evidence are you looking at to support the assertion that tech stack matters for tech debt?
Yes it does. Some languages protect you against shooting yourself in the foot, or encourage the right mindset, while others require more seasoned coders which are harder to hire (both in terms of numbers and also salary), so you’ll be letting less experienced programmers handle it in the earlier days. They will likely make it work but that’s only half the story. How they make it work also matters in the long run.
Bottomline is, to say that tech stack doesn’t matter is very naive. The statement lacks context at best.
I’d like to question the idea that using exotic technology or languages makes hiring hard. Anyone good should be able to ramp up with a new stack. Presumably you’re only cutting out people who don’t enjoy learning new things, which for a startup I consider a good thing.
Once you’re at the scale the business needs to just crank out features, you can either start to write replacement services in Java, or hire India’s best and brightest to learn your stack.
I do agree that exotic technology extracts a cost in terms of having less of a community to learn from. The benefits can still be substantial if the tech is much better fitted for your problem than the alternatives.
There is a serious problem in hiring. The mismatch between the hundreds of people looking for work in a stack and the hundreds hiring for that stack somehow keep failing to find each other. If your stack is bog standard, then at least you don’t have trouble finding someone who knows it and can work in it.
Except that the hard part is learning your domain and your codebase and everything else. Stuff like language and framework you just pick up as you go with the other, harder stuff.
As a regular sized company you need people who are willing to work in your stack, and there is a lack of confidence around hiring people who can then do the job well with the single added complication.
Not always. The stability/availability of your service can be a sell as well. For example you wouldn’t want your webshop provider to go down during Black Friday sales.
This has to be explained?
For product people probably (hopefully) no, but for tech people? Where do I even start? :D It’s kind of makes sense that for developers the only thing matter is the tech stack, that’s what we are hired for, but making it part of the culture to care about the customers and product needs effort IMO.
When we deal a new feature, the first thing I see are the features required, the second thing I see is how it will be accomplished in the tech stack.
For us, while we eventually have customers outside of the company - the product seems to be made for the internal groups. They have direct contact with external consumers (business users).
I can see how that would make it harder to see the external customer.
In my experience, a minority of engineers understand this. Not zero, but a minority. So I’m happy to have it called out.
Weeeell… In the early days, whatever you can put together and sell is fine. Later on though, if the company can manage to stick around, the tech stack will matter because it will determine how easy/hard it is to scale your engineering org. Tech stack also affects things like how easy/hard it is to accrue tech debt.
So, of course it does matter, but in most cases the company either doesn’t make it that far or get large enough for it to matter.
Does it, really? I would imagine this to be one of those things that might be hypothetically true in a vacuum, but in reality the effect is overwhelmed by more important factors such as engineering skill, communication, culture, economics, management style, etc.
What sort of evidence are you looking at to support the assertion that tech stack matters for tech debt?
Yes it does. Some languages protect you against shooting yourself in the foot, or encourage the right mindset, while others require more seasoned coders which are harder to hire (both in terms of numbers and also salary), so you’ll be letting less experienced programmers handle it in the earlier days. They will likely make it work but that’s only half the story. How they make it work also matters in the long run.
Bottomline is, to say that tech stack doesn’t matter is very naive. The statement lacks context at best.
I’d like to question the idea that using exotic technology or languages makes hiring hard. Anyone good should be able to ramp up with a new stack. Presumably you’re only cutting out people who don’t enjoy learning new things, which for a startup I consider a good thing.
Once you’re at the scale the business needs to just crank out features, you can either start to write replacement services in Java, or hire India’s best and brightest to learn your stack.
I do agree that exotic technology extracts a cost in terms of having less of a community to learn from. The benefits can still be substantial if the tech is much better fitted for your problem than the alternatives.
There is a serious problem in hiring. The mismatch between the hundreds of people looking for work in a stack and the hundreds hiring for that stack somehow keep failing to find each other. If your stack is bog standard, then at least you don’t have trouble finding someone who knows it and can work in it.
Except that the hard part is learning your domain and your codebase and everything else. Stuff like language and framework you just pick up as you go with the other, harder stuff.
Right but I’m arguing that as a startup you’re better off avoiding people who only want to work in a particular stack.
As a regular sized company you need people who are willing to work in your stack, and there is a lack of confidence around hiring people who can then do the job well with the single added complication.
Now, the really ugly truth:
This also applies to your tests.
Not always. The stability/availability of your service can be a sell as well. For example you wouldn’t want your webshop provider to go down during Black Friday sales.
Don’t deploy the day before and your tests matter less