12 ms·

I completed my role as a CTO for a company several years ago. I chose a boring stack with plenty of developers available: MySQL, PHP with Laravel, and Angular 2

I completed my role as a CTO for a company several years ago. I chose a boring stack with plenty of developers available: MySQL, PHP with Laravel, and Angular 2. Since then, I've been a founding engineer at some startups using the latest, cutting-edge tech stacks. I'm proud to announce that the stack I managed as CTO is still running stable and smooth with minimal intervention, and it remains easy to modify. Meanwhile, the startups with flashy stacks and nearly impossible-to-debug architectures have gone out of business. It amazes me how some companies still adopt the "build it and they will come" approach, and when confronted with harsh reality, they double down on building (and especially increasing architectural complexity). CEOs, if you can't attract customers with an idea or don't have a vertical that people are eager to pay for, cramming 1000 half-baked features into a microservice architecture and using the latest programming language / paradigm won't save your company!

goodrubyist 3y ago
Were those startups that went out of business did so because of their stacks/architecture, or are you confusing correlation with causation? And, there is a good reason people shy away from PHP, and it has nothing to do with trying to be "flashy." There should be a name for this kind of fallacy.
- iLoveOncall 3y ago
  > there is a good reason people shy away from PHP Please share it. And don't rely on articles that are more than a decade and 3 or 4 versions of PHP old.
  - 5Qn8mNbc2FNCiVV 3y ago
    Afaik you cannot discern null and undefined. So, not there and "null"? Either that or I'm going to have to have a good talk with my colleague
    - iLoveOncall 3y ago
      Go have your talk [1]. But that's a pretty weak argument anyway given that: 1. Other languages also do not have this distinction (Python for example AFAIK), 2. It's relatively useless. I get the value of it in JavaScript which has a lot of asynchronous code and frontend where the behavior may indeed be very different between null and undefined, but in a server-side application I don't think the nuance is necessary at runtime, and potential programming mistakes involving that can be caught by a linter. [1] https://stackoverflow.com/questions/6905491/how-to-tell-whether-a-variable-is-null-or-undefined-in-php https://stackoverflow.com/questions/6905491/how-to-tell-whet...
    - ThalesX 3y ago
      > Afaik you cannot discern null and undefined. This is a discussion for us tech folks. When it comes to business. Customers don't give a rat's ass about this as long as the product provides them with value. If you're flooded with customers and the tech stack is a pain in the ass, perhaps it would be a good time to start considering this, but until you have this problem, the technical aspects are just wasting investor money and / or engineering time.
      - resonious 3y ago
        When I (an average developer) accidentally check for null but not undefined in the code and it causes a bug, the customer might care a lot.
        ThalesX 3y ago
        There is always a balance to strike between development and delivery. When creating a system with high potential failure costs, it's important to select a technology stack that minimizes common errors for developers. For most companies, issues like `undefined | null` bugs can be resolved with just a few code adjustments, resulting in only minor inconvenience for customers. As long as problems are addressed and the product provides value, customers will continue to support it. There are CEOs and CTOs that feel differently. I wish them luck.
    - 3y ago
  - proxyon 3y ago
    How about the fact that most of us are experienced and can attest that PHP is the worst language we've ever used in our careers?
    - aarondf 3y ago
      Genuine question, when was the last time you wrote PHP?
      - proxyon 3y ago
        5 years ago and I wish I hadn't.
        chalcolithic 3y ago
        It was fine in the late 90s. Very adequate for the hosting landscape. I have not touched it since that time
    - jcparkyn 3y ago
      Spoken like someone who's never used Matlab :)
      - itake 3y ago
        > indexes start at 1 - no one -- Matlab
        MiyamotoAkira 3y ago
        Pascal had indexes starting at 1 too. Starting indexes at 0 makes sense when you want to enable the developer to manipulate memory (for example, C) Indexes starting at 1 matches with a more natural ordinal sequencing.
        haspok 3y ago
        > indexes starting at... "I don't understand the word 'index'". - a functional programmer
  - makeitdouble 3y ago
    IMHO this very discussion factors in whether you'll want a PHP stack or not. If you're looking for pragmatic devs that don't care much about the trends, the community or peers' general opinion about a technology, going with PHP will get you this type in spades. Especially if you're looking for experienced engineers. If you want devs that care about thoughtful designs, elegant solutions and want to enjoy the community, it will be a lot more difficult (not impossible, but it's an uphill battle) And this has little to do with PHP's viability per se, there's just so much baggage that most devs will self select in one side or another. A language's base design philosophy matters, and it's always better to chose a stack that matches your own philosophy.
- ThalesX 3y ago
  > Were those startups that went out of business did so because of their stacks/architecture, or are you confusing correlation with causation? As far as I am aware, and I can tell, it wasn't because of the stacks / architecture, but lack of product market fit. The fact that the response to lack of PMF was to double down on product features and tech (instead of a business pivot), in my opinion, was what made the investor money go poof and the startup die down. I've seen this happen' in too many places (as an employee or consultant) to be a coincidence. > And, there is a good reason people shy away from PHP, and it has nothing to do with trying to be "flashy." There should be a name for this kind of fallacy. Different stacks for different use cases. If I can't get money with a shitty PHP product offering, it's probably best to figure out why instead of attributing it to my tech stack.
  - wpietri 3y ago
    I have totally seen that too. For me one of the biggest dangers in any tech project, startups especially is caring about outputs more than outcomes. "Look at all the things we're building! Look at how hard we're working!" But those outputs don't matter if they aren't creating more value for the customer.
- jaapbadlands 3y ago
  The point wasn't that you should use PHP, it was to not jump on stack trends. There is a name for your kind of fallacy.
- JackMorgan 3y ago
  It's called survivorship bias (1). The only people pointing to PHP as the right choice that kept them from ruin are those that used it successfully. Therefore, they were building something that fit well with PHP's benefits and didn't expose too many of it's weaknesses. But no one knows for sure exactly what about that project made it a good candidate for a PHP monolith, because we don't really have any science around software engineering, just hearsay and fashion. Having rescued several 10+ person year PHP projects from ruin, none of them were on the edge because of the language itself. However, the people building those systems made an incredible mess in a short time. I think each language attracts a certain type of developer and comes with it's own community baggage. The PHP community has some highly questionable best practices. But this is true of all programming language specific communities. They tend to be insular and have a lot of "winning the last war" advice for working around the shortcomings of the language's previous major version that have been fixed in the current major version. (1) https://en.wikipedia.org/wiki/Survivorship_bias https://en.wikipedia.org/wiki/Survivorship_bias
  - ThalesX 3y ago
    > Having rescued several 10+ person year PHP projects from ruin How did you rescue them? What are your views on Laravel?
    - JackMorgan 3y ago
      The teams were generally adding more bugs per release then they were fixing. Many bugs were caused by duplicated code: "I fixed the bug, but only in 1/18th of the places it manifests." The projects were using Zend framework 2. We didn't change really anything about the text stack at all. The solutions were generally three pronged. This isn't to bash anyone, but every failing project I've seen is a skill, talent, or discipline issue, not a technical one. So recusing projects tends to be about training, mentorship, and guidance. Sure, you fix things along the way, but that's more to prove to the devs that you know what you're talking about, so they start to fix things themselves. First, start a root cause analysis on bugs before fixing them. This often meant that instead of another if statement in the UI because of bad state, there was a larger fix needed to prevent the bad state entirely. These bigger changes were scary, but they quickly turned these projects from spending all their time in emergencies into only a few hours a week. Second tool was to deduplicate and unit test code as much as possible. No more copy-pasting whole files every time there was a slightly different use-case required. Third, to stop treating the database like a PHP ORM connection and start treating it like a distinct tool. Things like turning serialized PHP arrays from a single column into separate tables allowed us to start using SQL to query data instead of pulling all records into memory to filter and sort. This rapidly improved performance, which meant fewer support issues. All boring, bog standard stuff. One project we started a second service in .NET to be the location of new features because half the team didn't want to use PHP anymore. The idea was they could slowly migrate endpoints to the .NET project. But that didn't survive. They got bored with a slow and safe conversion and convinced upper management to approve a total rewrite in .NET with a whole different team building out a microservice mess. The rewrite has been ongoing for 18 months now without a release. I heard they finished their first feature a few months ago, but still aren't live. Meanwhile the PHP project just keeps chugging along. Just goes to show, it's rarely the technology that causes issues, it's the team. I don't really know anything about Laravel. I'm not really a PHP guy, I'm a project rescuer. Just happens to be most projects I get called into are PHP, C#, and Visual Basic. I've heard really good things about Laravel, but even ZF2 can be made safe, secure, performant, and reliable. It just takes discipline and the right team. That being said, I would consider PHP to be a language that is hard to hire for. There's just so many developers that flood the inbox who don't even know what a function is. I will say, when I took a contract to build a greenfield web dashboard at the start of the year, I chose .NET 6 and C#. The platform and ecosystem is fine. I've shipped Java, Python, JavaScript, Ruby, Perl, OCaml, Haskell, Clojure, F#, and VB.NET. I picked C# for this project because the company already has a couple dozen C# developers who are pretty talented. I figured if I shipped them something they were comfortable with maybe they'd hire me again down the road.
- Tabular-Iceberg 3y ago
  > And, there is a good reason people shy away from PHP I agree, I also strongly dislike Angular and MySQL in addition to PHP. But I also think a much better indicator for success is discipline. Angular, PHP and MySQL, to their credit, aren’t crazy Turing tarpits, you can write good, successful software with them. I’ve never seen a dysfunctional project where any of the inherent flaws of those technologies even registered on the same scale as the sheer malpractice of everyone working on the product. And this is also the problem with trendy and flashy stacks, developers not learning the stacks properly and using them as intended. Probably due to commercial pressure to push prototypes to production instead of rebuilding properly after learning the stack. I think that should be the takeaway from the original comment, that CTOs need to either budget for building it twice, or stick to a stack everyone knows inside and out.
- _fat_santa 3y ago
  Personally I think the indicator of success is not necessarily X stack or Y stack, it's what stack are you most comfortable with? I think one of the problems with those startups you mentioned that used flashy stacks is they are not only fighting a battle to build the product, they are also fighting a battle to learn their way around the new stack they just adopted, and learning all the quirks with it. I don't think one stack is necessarily better than the other, it's all about how well do the developers know the tech stack in question.
o_m 3y ago
There is a middle ground to this. Sooner or later you have to upgrade. There might be a security upgrade or the old system doesn't play nice with other systems. So you are forced to upgrade to something more non-boring, even if you are using the same tech. It also get harded to hire developers. I doubt there is many devs that want to work on Angular 2 these days.
- ThalesX 3y ago
  The middle ground is that once the tech becomes the actual problem, it might be time to investigate possibilities, until then, customers don't care, business people doesn't care and the bottom line doesn't care. There are not that many companies in the world where the tech stack is their competitive advantage. > I doubt there is many devs that want to work on Angular 2 these days. From my experience, a product that makes money and is able to pay people at market rates, will find said people. Not everyone is an EMACS wielding, Linux wizard that refuses to touch tech out of idealistic concerns. The problem, in my experience, is more often lack of PMF than tech stack (I've seen customers give insane leeway to actually valuable products).
theK 3y ago
I agree with you that choosing a boring stack and focusing on down to earth, understandable and pragmatic architectural principles offers good probabilities to get a maintainable product. I would like to interject, though, that stack and architecture do not weigh equally on these probabilities. My observation has been that tech organizations fail when they loose their grip on pragmatism, regardless the stack. That doesn't mean that you should force the latest, unproven, JS framework on 200 engineers but if you have the culture for it one can easily succeed with react+JVM, elm+Haskell, etc. One interesting thing also is access to devs as each tech stack will attract different groups of the Dev society which will in turn affect your success chances.
yread 3y ago
I think it's because it's fun to work at a company that is tech-first (as opposed to just using tech as a tool for growing business) but it leads to doing things in complicated and risky ways "because we're a tech company"
- ThalesX 3y ago
  I guess it also depends on the person. I get off on providing customer value by addressing business needs. I scratch the other itch late at night with unspeakable horrors that never see the light of day.
Cthulhu_ 3y ago
http://boringtechnology.club/ http://boringtechnology.club/ remains relevant, and I try to apply it wherever I go with... varying results. One issue though is that it seems more difficult to find competent developers for boring stacks, because they're always looking for the next challenge, the next thing they consider interesting or what looks good on their profile (vs what is best for their employer).
- Volrath89 3y ago
  I'd love to work on a "boring" stack and just ship features and build stuff but... companies are like a herd, and they all ask for the same microservices' technologies when interviewing, no matter what they are building. So if I stay with a boring stack, I'd lose competitive advantage and face the potential of being "un-hirable" in the not-so-distant future.
  - intelVISA 3y ago
    Senior DevSecOps Engineer responsible for converged, cross-cloud cyber-resilience platform security vs unix greybeard who writes bash scripts to grep secrets in git repo They're the same, but the word salad ver is more understandable to VC and HR types
  - oaiey 3y ago
    Well ... that depends a lot on where you want to be hired. There is tons of companies which are not at all that interesting like the latest startup but deliver awesome stuff all the time. IMHO, there is not a correlation between developer technology and delivering awesome stuff. There is a correlation between management style and mental capability to delivering awesome stuff. I mean obviously we all have to move ourselves from "Fortran boring" to "Java boring" every decade or two, but being un-hirable because of "Java boring" is not a thing.
- cryptos 3y ago
  Maybe the word "boring" scare some people away, but it is a good contrast to exciting new technology anyway. "Mature" would probably the more appropriate term. Many times the exciting stuff is the problem domain itself. But developers tend to be more excited about new technologies than about customer needs.
jossclimb 3y ago
That sounds more like survivorship bias, startups typically fail over things such as product market fit, running out of cash, not how well the stack operates.
- papito 3y ago
  One way to run out of cash is to hire 50 expensive devs to build a microservices hairball with Kafkas and all the latest toys, as opposed to having 5 devs just knock it out, faster and better, with a single Python app and a Postgres database. We used to build real-scale systems with a stack of this kind when we had fewer features and less CPU power.

goodrubyist 3y ago

Were those startups that went out of business did so because of their stacks/architecture, or are you confusing correlation with causation? And, there is a good reason people shy away from PHP, and it has nothing to do with trying to be "flashy." There should be a name for this kind of fallacy.

iLoveOncall 3y ago
> there is a good reason people shy away from PHP Please share it. And don't rely on articles that are more than a decade and 3 or 4 versions of PHP old.
- 5Qn8mNbc2FNCiVV 3y ago
  Afaik you cannot discern null and undefined. So, not there and "null"? Either that or I'm going to have to have a good talk with my colleague
  - iLoveOncall 3y ago
    Go have your talk [1]. But that's a pretty weak argument anyway given that: 1. Other languages also do not have this distinction (Python for example AFAIK), 2. It's relatively useless. I get the value of it in JavaScript which has a lot of asynchronous code and frontend where the behavior may indeed be very different between null and undefined, but in a server-side application I don't think the nuance is necessary at runtime, and potential programming mistakes involving that can be caught by a linter. [1] https://stackoverflow.com/questions/6905491/how-to-tell-whether-a-variable-is-null-or-undefined-in-php https://stackoverflow.com/questions/6905491/how-to-tell-whet...
  - ThalesX 3y ago
    > Afaik you cannot discern null and undefined. This is a discussion for us tech folks. When it comes to business. Customers don't give a rat's ass about this as long as the product provides them with value. If you're flooded with customers and the tech stack is a pain in the ass, perhaps it would be a good time to start considering this, but until you have this problem, the technical aspects are just wasting investor money and / or engineering time.
    - resonious 3y ago
      When I (an average developer) accidentally check for null but not undefined in the code and it causes a bug, the customer might care a lot.
      - ThalesX 3y ago
        There is always a balance to strike between development and delivery. When creating a system with high potential failure costs, it's important to select a technology stack that minimizes common errors for developers. For most companies, issues like `undefined | null` bugs can be resolved with just a few code adjustments, resulting in only minor inconvenience for customers. As long as problems are addressed and the product provides value, customers will continue to support it. There are CEOs and CTOs that feel differently. I wish them luck.
  - 3y ago
- proxyon 3y ago
  How about the fact that most of us are experienced and can attest that PHP is the worst language we've ever used in our careers?
  - aarondf 3y ago
    Genuine question, when was the last time you wrote PHP?
    - proxyon 3y ago
      5 years ago and I wish I hadn't.
      - chalcolithic 3y ago
        It was fine in the late 90s. Very adequate for the hosting landscape. I have not touched it since that time
  - jcparkyn 3y ago
    Spoken like someone who's never used Matlab :)
    - itake 3y ago
      > indexes start at 1 - no one -- Matlab
      - MiyamotoAkira 3y ago
        Pascal had indexes starting at 1 too. Starting indexes at 0 makes sense when you want to enable the developer to manipulate memory (for example, C) Indexes starting at 1 matches with a more natural ordinal sequencing.
        haspok 3y ago
        > indexes starting at... "I don't understand the word 'index'". - a functional programmer
- makeitdouble 3y ago
  IMHO this very discussion factors in whether you'll want a PHP stack or not. If you're looking for pragmatic devs that don't care much about the trends, the community or peers' general opinion about a technology, going with PHP will get you this type in spades. Especially if you're looking for experienced engineers. If you want devs that care about thoughtful designs, elegant solutions and want to enjoy the community, it will be a lot more difficult (not impossible, but it's an uphill battle) And this has little to do with PHP's viability per se, there's just so much baggage that most devs will self select in one side or another. A language's base design philosophy matters, and it's always better to chose a stack that matches your own philosophy.
ThalesX 3y ago
> Were those startups that went out of business did so because of their stacks/architecture, or are you confusing correlation with causation? As far as I am aware, and I can tell, it wasn't because of the stacks / architecture, but lack of product market fit. The fact that the response to lack of PMF was to double down on product features and tech (instead of a business pivot), in my opinion, was what made the investor money go poof and the startup die down. I've seen this happen' in too many places (as an employee or consultant) to be a coincidence. > And, there is a good reason people shy away from PHP, and it has nothing to do with trying to be "flashy." There should be a name for this kind of fallacy. Different stacks for different use cases. If I can't get money with a shitty PHP product offering, it's probably best to figure out why instead of attributing it to my tech stack.
- wpietri 3y ago
  I have totally seen that too. For me one of the biggest dangers in any tech project, startups especially is caring about outputs more than outcomes. "Look at all the things we're building! Look at how hard we're working!" But those outputs don't matter if they aren't creating more value for the customer.
jaapbadlands 3y ago
The point wasn't that you should use PHP, it was to not jump on stack trends. There is a name for your kind of fallacy.
JackMorgan 3y ago
It's called survivorship bias (1). The only people pointing to PHP as the right choice that kept them from ruin are those that used it successfully. Therefore, they were building something that fit well with PHP's benefits and didn't expose too many of it's weaknesses. But no one knows for sure exactly what about that project made it a good candidate for a PHP monolith, because we don't really have any science around software engineering, just hearsay and fashion. Having rescued several 10+ person year PHP projects from ruin, none of them were on the edge because of the language itself. However, the people building those systems made an incredible mess in a short time. I think each language attracts a certain type of developer and comes with it's own community baggage. The PHP community has some highly questionable best practices. But this is true of all programming language specific communities. They tend to be insular and have a lot of "winning the last war" advice for working around the shortcomings of the language's previous major version that have been fixed in the current major version. (1) https://en.wikipedia.org/wiki/Survivorship_bias https://en.wikipedia.org/wiki/Survivorship_bias
- ThalesX 3y ago
  > Having rescued several 10+ person year PHP projects from ruin How did you rescue them? What are your views on Laravel?
  - JackMorgan 3y ago
    The teams were generally adding more bugs per release then they were fixing. Many bugs were caused by duplicated code: "I fixed the bug, but only in 1/18th of the places it manifests." The projects were using Zend framework 2. We didn't change really anything about the text stack at all. The solutions were generally three pronged. This isn't to bash anyone, but every failing project I've seen is a skill, talent, or discipline issue, not a technical one. So recusing projects tends to be about training, mentorship, and guidance. Sure, you fix things along the way, but that's more to prove to the devs that you know what you're talking about, so they start to fix things themselves. First, start a root cause analysis on bugs before fixing them. This often meant that instead of another if statement in the UI because of bad state, there was a larger fix needed to prevent the bad state entirely. These bigger changes were scary, but they quickly turned these projects from spending all their time in emergencies into only a few hours a week. Second tool was to deduplicate and unit test code as much as possible. No more copy-pasting whole files every time there was a slightly different use-case required. Third, to stop treating the database like a PHP ORM connection and start treating it like a distinct tool. Things like turning serialized PHP arrays from a single column into separate tables allowed us to start using SQL to query data instead of pulling all records into memory to filter and sort. This rapidly improved performance, which meant fewer support issues. All boring, bog standard stuff. One project we started a second service in .NET to be the location of new features because half the team didn't want to use PHP anymore. The idea was they could slowly migrate endpoints to the .NET project. But that didn't survive. They got bored with a slow and safe conversion and convinced upper management to approve a total rewrite in .NET with a whole different team building out a microservice mess. The rewrite has been ongoing for 18 months now without a release. I heard they finished their first feature a few months ago, but still aren't live. Meanwhile the PHP project just keeps chugging along. Just goes to show, it's rarely the technology that causes issues, it's the team. I don't really know anything about Laravel. I'm not really a PHP guy, I'm a project rescuer. Just happens to be most projects I get called into are PHP, C#, and Visual Basic. I've heard really good things about Laravel, but even ZF2 can be made safe, secure, performant, and reliable. It just takes discipline and the right team. That being said, I would consider PHP to be a language that is hard to hire for. There's just so many developers that flood the inbox who don't even know what a function is. I will say, when I took a contract to build a greenfield web dashboard at the start of the year, I chose .NET 6 and C#. The platform and ecosystem is fine. I've shipped Java, Python, JavaScript, Ruby, Perl, OCaml, Haskell, Clojure, F#, and VB.NET. I picked C# for this project because the company already has a couple dozen C# developers who are pretty talented. I figured if I shipped them something they were comfortable with maybe they'd hire me again down the road.
Tabular-Iceberg 3y ago
> And, there is a good reason people shy away from PHP I agree, I also strongly dislike Angular and MySQL in addition to PHP. But I also think a much better indicator for success is discipline. Angular, PHP and MySQL, to their credit, aren’t crazy Turing tarpits, you can write good, successful software with them. I’ve never seen a dysfunctional project where any of the inherent flaws of those technologies even registered on the same scale as the sheer malpractice of everyone working on the product. And this is also the problem with trendy and flashy stacks, developers not learning the stacks properly and using them as intended. Probably due to commercial pressure to push prototypes to production instead of rebuilding properly after learning the stack. I think that should be the takeaway from the original comment, that CTOs need to either budget for building it twice, or stick to a stack everyone knows inside and out.
_fat_santa 3y ago
Personally I think the indicator of success is not necessarily X stack or Y stack, it's what stack are you most comfortable with? I think one of the problems with those startups you mentioned that used flashy stacks is they are not only fighting a battle to build the product, they are also fighting a battle to learn their way around the new stack they just adopted, and learning all the quirks with it. I don't think one stack is necessarily better than the other, it's all about how well do the developers know the tech stack in question.

o_m 3y ago

There is a middle ground to this. Sooner or later you have to upgrade. There might be a security upgrade or the old system doesn't play nice with other systems. So you are forced to upgrade to something more non-boring, even if you are using the same tech. It also get harded to hire developers. I doubt there is many devs that want to work on Angular 2 these days.

ThalesX 3y ago
The middle ground is that once the tech becomes the actual problem, it might be time to investigate possibilities, until then, customers don't care, business people doesn't care and the bottom line doesn't care. There are not that many companies in the world where the tech stack is their competitive advantage. > I doubt there is many devs that want to work on Angular 2 these days. From my experience, a product that makes money and is able to pay people at market rates, will find said people. Not everyone is an EMACS wielding, Linux wizard that refuses to touch tech out of idealistic concerns. The problem, in my experience, is more often lack of PMF than tech stack (I've seen customers give insane leeway to actually valuable products).

theK 3y ago

I agree with you that choosing a boring stack and focusing on down to earth, understandable and pragmatic architectural principles offers good probabilities to get a maintainable product. I would like to interject, though, that stack and architecture do not weigh equally on these probabilities. My observation has been that tech organizations fail when they loose their grip on pragmatism, regardless the stack. That doesn't mean that you should force the latest, unproven, JS framework on 200 engineers but if you have the culture for it one can easily succeed with react+JVM, elm+Haskell, etc. One interesting thing also is access to devs as each tech stack will attract different groups of the Dev society which will in turn affect your success chances.

yread 3y ago

I think it's because it's fun to work at a company that is tech-first (as opposed to just using tech as a tool for growing business) but it leads to doing things in complicated and risky ways "because we're a tech company"

ThalesX 3y ago
I guess it also depends on the person. I get off on providing customer value by addressing business needs. I scratch the other itch late at night with unspeakable horrors that never see the light of day.

Cthulhu_ 3y ago

http://boringtechnology.club/ http://boringtechnology.club/ remains relevant, and I try to apply it wherever I go with... varying results. One issue though is that it seems more difficult to find competent developers for boring stacks, because they're always looking for the next challenge, the next thing they consider interesting or what looks good on their profile (vs what is best for their employer).

Volrath89 3y ago
I'd love to work on a "boring" stack and just ship features and build stuff but... companies are like a herd, and they all ask for the same microservices' technologies when interviewing, no matter what they are building. So if I stay with a boring stack, I'd lose competitive advantage and face the potential of being "un-hirable" in the not-so-distant future.
- intelVISA 3y ago
  Senior DevSecOps Engineer responsible for converged, cross-cloud cyber-resilience platform security vs unix greybeard who writes bash scripts to grep secrets in git repo They're the same, but the word salad ver is more understandable to VC and HR types
- oaiey 3y ago
  Well ... that depends a lot on where you want to be hired. There is tons of companies which are not at all that interesting like the latest startup but deliver awesome stuff all the time. IMHO, there is not a correlation between developer technology and delivering awesome stuff. There is a correlation between management style and mental capability to delivering awesome stuff. I mean obviously we all have to move ourselves from "Fortran boring" to "Java boring" every decade or two, but being un-hirable because of "Java boring" is not a thing.
cryptos 3y ago
Maybe the word "boring" scare some people away, but it is a good contrast to exciting new technology anyway. "Mature" would probably the more appropriate term. Many times the exciting stuff is the problem domain itself. But developers tend to be more excited about new technologies than about customer needs.

jossclimb 3y ago

That sounds more like survivorship bias, startups typically fail over things such as product market fit, running out of cash, not how well the stack operates.

papito 3y ago
One way to run out of cash is to hire 50 expensive devs to build a microservices hairball with Kafkas and all the latest toys, as opposed to having 5 devs just knock it out, faster and better, with a single Python app and a Postgres database. We used to build real-scale systems with a stack of this kind when we had fewer features and less CPU power.