20 ms·

Happiness is a Boring Stack

558 points by jasonkester 10y ago

qaq 10y ago
You can have both happiness and an interesting stack a good example of this is Elixir or I would guess F# in the .Net world.
sarreph 10y ago
I've been thinking a lot about this recently. I'm in between jobs and thinking of starting a SAAS on the side in order to support my goal to go backpacking for a few months next year. However, the amount of microservices I'm thinking of putting it all together with means it'll require a decent amount of non-automatable (as far as I can tell) maintenance and attention. This isn't exactly what I want at the back of my mind all the time while travelling... but then again, you can't have all your cake and eat it. Anyone who has a successful hands-off SAAS built on a modern stack care to chip in on ways of mitigating this?
- dtien 10y ago
  How about don't go with a microservice arch. Nothing wrong with tried and true monolith Django, Rails, or [your favorite stack]. In fact, sounds like this is your first time out, in which case I would absolutely recommend minimizing the headache and complexity and go with a simple monolithic stack. [insert rant about premature optimization] In any case, build your SaaS, go backpacking. Both invaluable experiences.
- bensummers 10y ago
  Write it as a monolith. If you get to a stage where it needs a bigger server than you can afford, run a profiler on it, and fix up any glaring performance problems. Then if it gets wildly successful and does actually need microservices, then you have the resources to pay for the development & sysadmin overhead. Also by delaying as long as possible, you'd have the maximum information and maximise your chances of getting the split right.
- jasonkester 10y ago
  Expanding on the "both/and" advice from elsewhere in this thread, I'd recommend saving for the backpacking trip first with a boring-yet-lucrative consulting gig, then building the SaaS product during your downtime on the road. It'll fix your expectations and your finances all in one go. SaaS businesses take at least a year or so to ramp up to the point where they can reliably support you (even on the beach in Cambodia). It'd be a shame to have to cut your trip short because the thing you'd built wasn't immediately successful. With luck, it'll be the thing that finances your second lap around the world three years from now. [edit] And yeah, don't build microservices. Especially for a B2B SaaS. Scaling problems for products with a price tag are things that come with tons of money attached. Use that to scale when and if it becomes a "problem". For now, build a boring Rails app on PostgreSQL or whatever has the least chance of falling over while you're halfway down the Inca Trail.
- MikeKusold 10y ago
  Organize your microservices as packages, then run it as a monolith. Host it on Heroku. Now you have no ops, and no automation needed. Once your business grows to the point where you need to scale, you can easily split apart your monolith and you can host it on AWS (Heroku makes it easy to migrate your database to AWS).
- UK-AL 10y ago
  Write it as a monolith, but easily converted to microservices. I find you need a monolith phase anyhow to find out your real microservice boundaries before guessing.
- brightball 10y ago
  Elixir is a solid solution for this. You essentially write micro services as a monolith that runs on the BEAM VM and naturally spreads across a cluster (https://elixirschool.com/lessons/advanced/umbrella-projects/ https://elixirschool.com/lessons/advanced/umbrella-projects/). It's all message passing without shared memory so whether you're sending something to a different function, process, processor or machine in a different datacenter your code doesn't really care. As a bonus you don't have to define REST/SOAP/Protocol Buffer interfaces for every single microservice you're writing...since it's just function calls. Everything works smoothly and efficiently just like boring Erlang has for decades, with some readability and productivity perks that Elixir gives you. Elixir sounds trendy and new, but it's just modernized Erlang. It's older than Linux.
  - amorphid 10y ago
    I <3 actors & immutability. I didn't understand what "easy to reason about" meant until learning Elixir.
    - cutler 10y ago
      Yes, I loved Elixir as soon as I set eyes on it. However, as far as "easy to reason about" goes, Clojure in an Emacs CIDER repl is about as good as it gets.
- arikfr 10y ago
  There aren't many SaaS services I can think of that can be truly hands-off to the extent that you can backpack with a free mind. Also scaling a SaaS business takes time and significant effort. All of the above is from personal experience. If I were looking for passive income from software I would've looked at desktop software.
milesf 10y ago
This what I like to call "both/and". I like both the old reliable and the new shiny. So often people want things to be "either/or". Either I'm going to use this solution or that one. The key is to know the context of each, and I think this article does a very good job of describing when each ought to be used. He uses the boring reliable stuff on his own things, because he is beholden to no one and does not need to justify his decisions. And he also works with the exciting new stuff with clients, because it is simply easier to sell it to clients who are caught in the Silicon Valley echo chamber. Both/And is like trying to hold a small bird in your hand: too tight and you'll crush the bird and it will die, too loose and it will fly away.
- nxc18 10y ago
  Its interesting to note that there is an inversion here. You'd think that for one's own enjoyment, the new and shiny would be the natural choice, while dependable and stable long-term would be reserved for people who need dependability and reliability long term (a.k.a. Clients).
  - ynniv 10y ago
    There is no inversion: new and shiny is what clients want, boring and dependable is what owners want. In this example he owns the boring products, and builds the shiny ones.
    - gjvc 10y ago
      "new and shiny is what clients want, boring and dependable is what owners want" excellent summary.
  - bunderbunder 10y ago
    I think it comes down to how you want to spend your free time. Some folks like to spend it building new things, and don't want to be hampered by having to spend time learning the ins and outs of $fancy_new_thing. Others like to spend it playing with new things, and don't like to be hampered by any technical limitations of $boring_old_thing.
rch 10y ago
In other words: 'When you have the option, use the stack you're most comfortable with'.
- bunderbunder 10y ago
  It's not just comfort, it's that stuff that's been around the block a few times tends to fall into one of two categories: Stuff that's solid and stable and not very fussy, and stuff that nobody uses anymore because it's a PITA. That makes it pretty easy to make good technology decisions. Newer technology tends, almost by definition, to be very experimental. And experimental means, almost by definition, that some ideas are going to work out and others aren't. Oftentimes it takes a while to figure out which is which. And popularity, even extreme popularity, tends not to be a good proxy for robustness - if anything, it's a source of noise that only makes it harder to figure out what's robust because hype tends to be a pretty darned autoregressive process.
  - amorphid 10y ago
    I find Elixir easier than Ruby and Javascript, one you figure the actor model, dialyzer, and reading other people's macros.
  - rch 10y ago
    Sure, but longevity alone is an insufficient criterion. There are a few venerable, perfectly adequate, stacks (for lack of a better term) that I would rather not start new projects with. I say this as someone who once had to argue forcefully to start a new project in .Net while it was still in beta.
sdegutis 10y ago
Fully agree. We're moving our work codebase from Clojure to Java. It's true that Java is boring and old and simple. That's what makes it great! Now we can focus 100% of our efforts on the business logic rules. (Granted, sometimes I wish we were using C# instead. But only sometimes.)
- ungzd 10y ago
  Clojure is real boring stack. No abstract singleton proxy factories, just plain scripting. I have web application in production using plain Ring API, without frameworks. Like good old days of CGI and PHP but more sane.
  - edwinnathaniel 10y ago
    > No abstract singleton proxy factories I barely see this in the code that I wrote given that I've been writing Java code for ... 8 years? (unless you're writing Spring framework itself) Can we please drop this?
    - kelnos 10y ago
      > Can we please drop this? I would love to agree with that, but I don't think we can. I've been writing Java (well, more recently Scala) for 14+ years, and I still see otherwise great programmers succumb to Java class-itis.
      - lacampbell 10y ago
        I see a lot of bad C# code, but I don't feel the need to make snide comments about C# whenever I see or hear it mentioned. It's pretty clear to me it's not the languages fault. There's nothing in Java forcing you to make deep class hierarchies or leaky abstractions.
        kelnos 10y ago
        Nothing that forces you, sure. But when you have a culture following that language for so long that encourages that, and have existing 3rd-party libraries and an ecosystem that makes it easier to do that... well, that's what happens. Not sure about the GP of my original comment, but I'm not trying to be snide; I just see it everywhere, and it really frustrates me. I don't see it with Scala/C++/python/ruby programmers, so what's the common denominator? The language.
bluejekyll 10y ago
> Good old C#, SQL Server and a proper boring stack And? What is the proper boring stack for targeting a browser? The reason React is so popular is because it answers a fundamental problem of application delivery to the browser client. If you're living in C# land that's not always boring either, as soon enough you have a GC nightmare. I agree with everything in this article in principle, but it fails to leave room for innovation, where innovation is necessary. And an MS stack when 80% of the world deploys to Linux on the serverside. You might be stuck in the wrong decade...
- rpeden 10y ago
  If you're running a small SaaS company, it doesn't matter all that much what 80% of the world is doing. I used to feel the same way you do. My apps were all Ruby or Java, usually with Postgres, deployed on Linux. My past couple of employers, though, have used C# and SQL Server running on Windows Server. And they've both been able to handle heavy workloads without using a huge amount of resources. I'd think twice about using SQL Server if I were launching a small SaaS app due to licensing costs. But the extra cost of a Windows VM wouldn't hurt much if I had more than a couple of users. And I know from personal observation that a relatively boring Windows/IIS/.NET stack would handle the workload of my SaaS app without breaking a sweat. And there's no reason you couldn't mix in React on the front end. I haven't run into any noticeable GC issues even while running heavy workloads, but I could see it being an issue depending on the type of work you do. That's not to say you shouldn't deploy a cutting edge web stack on Linux or the BSD of your choice. You can certainly be successful that way too. Perhaps a balance is best: use boring, battle tested technology where you can, and use the cutting edge tech in places where it will give you a competitive advantage.
- vlunkr 10y ago
  I like React, but it's delusional to think you can't target a browser without it. I mean, we lived without front end frameworks for a loong time before that.
  - bluejekyll 10y ago
    I'm not saying you can't target a browser without it, I'm saying it answers a development problem of having rich applications built on the clientside.
ungzd 10y ago
Maybe yes, when you work at bank, change 1 line of code per month, documenting this change in 10 Word documents, most of time drinking coffee and sleeping during Powerpoint presentations with 1000 attendees.
- crpatino 10y ago
  You are not being paid to change 1 line of code per month. You are being paid to be a living repository of institutional knowledge: so you (can) know (in a finite, bounded time) what line to change in order to achieve the business requirement, and what dozen-or-so Word documents you need to read in order to confirm which unintended consequences may result of that change. That said, sleeping during massive presentations will hinder your abilities as a living repository... so, hang in there and keep pouring-in the coffee.
lmm 10y ago
Low maintenance is important, but so is functionality. It's frustrating to have to fix code that was working and gets broken by some update, but it's even more frustrating to have to copy/paste code because your language doesn't have the abstraction facilities that let you factor out the commonality.
- edwinnathaniel 10y ago
  > but it's even more frustrating to have to copy/paste code because your language doesn't have the abstraction facilities that let you factor out commonality. I find this statement to be less of a problem in many modern programming languages (or greatly exaggerated by a specific language fan when comparing his/her preferred tools vs "the other languages).
  - lmm 10y ago
    I think in higher-kinded types these days, and can't stand to use a language without them (where I necessarily end up copy-pasting). There are plenty of modern languages without that. I've only had to copy-paste code because of Scala's lack of support for polykinded code a few times, but it was very frustrating every time. Hardly any languages, even modern ones, support that.
- UweSchmidt 10y ago
  What language doesn't have abstraction facilities to factor out commonality? Even assembler has macros :-)
  - lmm 10y ago
    Misspoke; I meant "don't let you factor out that particular piece of commonality".
- crpatino 10y ago
  If you think copy&paste is an option at all, I agree. If you are to rely on somebody else's work, better make it work they have put an actual effort in getting right, for which they have some stakes. Doing "boring stack" implies you actually know what you are doing, though.
mixmastamyk 10y ago
I agree in general but why would you use Windows/SQLSrv for internet-based products? I'm fine with it on the desktop, but the extra costs and time devoted to things like activation are a non-starter as far as I'm concerned. I believe they finally have ssh and package mgrs available, but don't you still have to install them manually? There's plenty of boring stacks on Unix that are free, in both senses of the word.
- smacktoward 10y ago
  Because it's what you already know? Teaching yourself *nix from scratch isn't free. Because there's some other piece of software you want to use that requires it? (Lots of people seem to like MS SQL Server, for example.)
- wvenable 10y ago
  Activation? I do development in both stacks, and there are pros and cons to each. For Windows, the biggest con is really cost. If you're comfortable with both stacks the difference in setup/maintenance isn't very different. However, the author makes a good argument about boring stacks in general. Your boring Linux stack will be much easier to maintain than something on bleeding edge.
- rpeden 10y ago
  Because it performs well, and the cost of Windows licenses ends up being a rounding error if you have paying users. I've administered Linux boxes for years, and while I enjoy it I find Windows Server more enjoyable to work with in many cases. SQL Server licensing is another story. It is expensive, but I've also seen it handle heavy workloads on modest hardware without complaining. Though I don't doubt the same is true for Postgres and MySQL/MariaDB/Percona. From what I've seen, the constellation of reporting and BI tools around SQL Server are what make it appealing to enterprises regardless of cost.
  - bad_user 10y ago
    Windows being a rounding error is kind of a myth perpetuated by people that haven't been in the position to buy Windows licenses for a company. First of all most software developers are not working in the consumer space. And for B2B you often get asked to have an on-premises option, either because the company doesn't trust you with their data, or because non-stop Internet connectivity can be a problem. And when deploying on-premises, the cost of the Windows licenses do matter a lot. If the clients are just web browsers then you can save the company a lot of money, since the clients can be just terminals powered by whatever you can get your hands on. But if you assume Windows clients, well, the costs can be huge. And on the server side, remote maintenance is way cheaper with Linux boxes, because well, you can control anything on a remote Linux machine, securely, reliably and for free. Add to that the licensing cost of Windows, which isn't cheap because you can't run a server on Home edition. Basically if your solution assumes Windows in any way on the customer's side, you're just adding unwanted cost that could have been your profit. And SQL Server is simply unjustifiable.
dahdum 10y ago
"It seems like on a lot of stacks, keeping the server alive, patched and serving webpages is a part-time job in itself. In my world, that's Windows Update's job." I imagine the Linux alternative of this would be Debian with unattended-upgrades and a PHP app.
- edwinnathaniel 10y ago
  PHP/Java/Perl. Python used to be in the list before every body in the neighbor wrote their own framework and/or different flavors of library that solve the same problem :p.
- icebraining 10y ago
  Sounds about right. I run Tiny Tiny RSS with Postgres and Nginx on Debian Stable and I can't remember the last time I've had to spend time administering it. (I do update TTRSS itself manually, but since it's behind Nginx's basic auth, I don't feel rushed to plug security holes). The truth is, as shown by data, that downtimes is usually caused by developers, not stuff crashing by itself.
libeclipse 10y ago
This is how I feel. I have friends that are always going on about all the latest "best practices" and cool hipster stuff like docker swarms and microservices. Meanwhile I've kept my own projects using boring old (or rather tried and tested) technologies and languages like python. I don't like it when people are recommending new buzz words every week.
- matt_wulfeck 10y ago
  Unfortunately the new buzz words of today are the boring stacks of tomorrow. I would say that containers represent a greater leap forward in thinking than a new programming language. Like it or not your future applications will run in a linux container.
  - crpatino 10y ago
    It is still worth it to delay adoption by a year or two. By then, early adopters have already stepped on most mines, flaky fads have crashed and burned, and the real winners of next generation stack-wars will have coalesced around something reseabling sustainable best practices.
    - matt_wulfeck 10y ago
      I agree. Letting things shake out is an important part of not losing your hair. At the very least you come into an ecosystem with mature third-party libraries.
      - jandrese 10y ago
        And documentation, or at least answers on Stackexchange. Documentation often lags behind on these new projects, especially when they're in a state of flux and you can easily find yourself pulling your hair out because the docs are for two versions ago and wrong now.
    - nickpsecurity 10y ago
      What you said was standard practice for savvy buyers of Windows for around a decade. We always told people, "Just wait till at least SP1 to buy it. You won't regret being a late adopter." We never did regret it.
jsingleton 10y ago
I really like C# and .NET as a stack, just like the OP. It may not be cool but it works well and they are good skills to have for stable employment prospects. The new .NET Core stuff is looking very promising too. I really hope it takes off, and not just because I have a book out on it :).
- aswanson 10y ago
  On top of that, it has a powerful, well-documented IDE and support community. It is what it is. I love to experiment with new stacks and paradigms but if I want to Get Shit Done, nine times out of 10 Im going with older tools.
apolymath 10y ago
omg this guy is on spot. My day job is Magento (hell), but I am absolutely in love with boring ol' C#, along with the new ASP.NET Core framework & Kestrel web server. All of my side projects are built using C#, and I don't use jQuery or Angular or React or Reactive. I use plain old vanilla javascript, because I care about zero HTTP requests & zero bloat & zero BS.
- UK-AL 10y ago
  Applications that don't rely on large js frameworks, tend to feel snappier as well.
  - cle 10y ago
    They also tend to turn into huge messy hairballs after years of developers and new business use cases. Not that these are use cases for personal projects, but standardized frameworks are valuable for large teams with lots of changing use cases and long-term maintenance requirements.
    - mattnewton 10y ago
      I've seen plenty of Ember apps succumb to the same syndrome- the problem is the developers, who are either incompetent or contractors who care only about the deadline before them. I don't think a framework is a magic cure for bad developers, though maybe because you wrote less code to start it probably does take longer to get to spaghetti hell.
    - tboyd47 10y ago
      It's usually not so bad if you can just keep the amount of client-side code down.
    - ksk 10y ago
      I don't see any long term stability and support in any JS framework. They seem to pop in and out of existence at a fairly rapid pace. What examples do you have of long-term projects that use those frameworks?
sly010 10y ago
Agree. Things like Docker and microservices architecture are solutions for problem you have only if you are playing with more "interesting" stacks.
- UK-AL 10y ago
  Tbh we use an NServiceBus(.net) microservice stack, and it's been pretty boring and uneventful for us.
drather19 10y ago
I like the point about building systems that take care of themselves and are largely hands-free. I'd say that applies regardless of platform (or "shininess"), though. The author has clearly internalized one of the more important lessons in engineering in terms of designing for maintainability (with an ultimate goal of zero/low-effort maintenance and/or extension). I'm not sure the platform itself is as important to achieving this goal so much as the decision-making ability of the engineers themselves, though. Maybe a tendency to pick shiny because of shiny is just a way that poor decision-making surfaces? However, I don't see a problem picking an appropriate solution that happens to be shiny. Anyways, kudos for sharing the wisdom.
elliotec 10y ago
This is my feeling about Rails. I've created several Rails apps that delighted the customer, and most have required literally zero maintenance after years of use. Sprinkle in a bit of jQuery and you have an app that is stronger and just as fancy-feeling as a mess of a massive client-side app.
- cutler 10y ago
  I think the improvements to turbolinks in Rails 5 make pjax more of an option now. Also, for scaling remember it's not the end of the road for Rails when you're running out of processes to keep up with requests. JRuby 9000 has been gathering a lot of momentum recently and promises huge performance gains when Truffle and Graal kick in. Migrating a Rails app to JRuby is not that difficult.
josep2 10y ago
This is a refreshing take, although maybe extended a bit too far. It seems like this kind of thinking is mostly in the real of software on the web and not necessarily on the systems side of things.
matchagaucho 10y ago
C# and SQL I might agree with. But ASP.NET and MVC = stable? All the hidden view state and POST backs to re-render the UI... terribly difficult to troubleshoot and support in my experience.
- UK-AL 10y ago
  That's ASP.Net WebForms which is basically very old and legacy.
  - pjmlp 10y ago
    I wish. Even this year I was getting some SiteCore requests, which I didn't accept, but version 6 was largely built on top of forms. I haven't bothered with it since version 6, so I don't know how well it has moved into MVC world.
    - yareally 10y ago
      Seconded. Sadly, our tech stack at work still includes some webforms cruft and I have a few friends at other companies that also still have to deal with them. Could be worse I guess...I know someone that still has to put up with classic ASP. Thankfully I work with backend stuff at my job currently or I'd probably go crazy dealing with a mishmash of mvc and web forms. Webforms are not super easy to get rid of if you weren't careful on how you coupled to them, so I think some code is still being added to ours.
    - flukus 10y ago
      Same with sharepoint, although apparently that supports MVC now too.
- yareally 10y ago
  > "All the hidden view state and POST backs to re-render the UI... terribly difficult to troubleshoot and support in my experience." You're confusing webforms (with viewstates) and .net MVC, which is stateless. http://stackoverflow.com/questions/23623229/what-is-the-equivalent-of-viewstate-in-asp-net-mvc http://stackoverflow.com/questions/23623229/what-is-the-equi...
rpeden 10y ago
Jeff Atwood made similar points in The Magpie Developer: https://blog.codinghorror.com/the-magpie-developer/ https://blog.codinghorror.com/the-magpie-developer/ and Why Ruby?: https://blog.codinghorror.com/why-ruby/ https://blog.codinghorror.com/why-ruby/ Not that chasing after the latest and greatest is always a bad thing, but sometimes existing (and relatively boring) tools are the best ones for the job at hand.
- majewsky 10y ago
  Not related to the article, but I couldn't help but chuckle at this part from the "Why Ruby" post: > It is just not a native part of the Microsoft .NET culture to make things open source
- zengid 10y ago
  From "why ruby": >Ruby isn't cool any more. Yeah, you heard me. It's not cool to write Ruby code any more. All the cool people moved on to slinging Scala and Node.js years ago. Our project isn't cool, it's just a bunch of boring old Ruby code. Personally, I'm thrilled that Ruby is now mature enough that the community no longer needs to bother with the pretense of being the coolest kid on the block. This is my feeling right now. Nobody is yelling about Ruby so I can take my time and enjoy learning it at my own pace.
deleted 10y ago
[deleted]
clifanatic 10y ago
Well, I don't know if "boring" is the word I'd use, but I like _transparent_ stacks: if I make a mistake, it tells me where I made a mistake in a way that I can interpret. All of the "boring" stacks have this property.
- jimbokun 10y ago
  I think this is the biggest selling point for Functional Programming. You know given these inputs, you will always get the same output. Even if not using a Functional Programming language, it is good practice to write your code to follow this principle whenever possible. I think this is what mocks and unit tests try to achieve, creating a scenario where given certain inputs, you know what the output will be.
  - nikanj 10y ago
    From what I've seen, functional programming doesn't really excel at error messages
    - edgyswingset 10y ago
      Sure it can - here's an example of an error message added to F# which suggests valid names for Record labels when you've typed an incorrect one: https://github.com/Microsoft/visualfsharp/pull/1102 https://github.com/Microsoft/visualfsharp/pull/1102 Don't confuse correlation (some functional programming languages out there don't have good error messages) with causation (functional programming languages don't excel at good error messages).
      - reitanqild 10y ago
        Elm is also said to be a good example. Haven't gotten around to really test it after hello world though but what I read was somewhat convincing.
        616c 10y ago
moduspwnens14 10y ago
It's a great point--it just seems arbitrary to draw the line in the sand of having a "boring stack" that consists of SQL Server and C#. I mean, that, as a minimum, means you're running and maintaining a Windows server, along with antivirus, backups for the OS, and backups for the database. Any time Windows updates come along, your service will be unavailable. Every couple of years, you'll need to buy a new license, upgrade Windows, and make sure everything comes up smoothly. This likely will involve fixing and troubleshooting some issues. You'll need to have some monitoring set up to make sure you don't end up running out of disk space on Saturday morning. Or maybe you have more than one Windows server (to avoid downtime from a single server), but that makes your stack decidedly less "boring." Now you're dealing with at least a load balancer and making SQL Server redundant. I mean, I guess it's more boring than chasing the latest front-end reinvention or maintaining MongoDB, but there's some room for improvement here, clearly. Containerized deployments (via Docker or a "serverless" architecture) might be able to help.
- bunderbunder 10y ago
  > I mean, that, as a minimum, means you're running and maintaining a Windows server, along with antivirus, backups for the OS, and backups for the database. By contrast, if you're on the LAMP stack then you won't need a Linux box, and since you don't have a server you definitely won't need to secure it or back it up. It'll all just run on clouds or something, I guess.
  - moduspwnens14 10y ago
    No, the point is relative to being containerized, where you're deciding ahead of time what needs to be backed up (outside the container) and what doesn't. This leads to backups and restores being easier and more "boring." It's also counter to one of themes of the post, which suggests by choosing this boring stack, he can just leave it alone for months at a time without touching it (presumably relative to other stacks). You can do that--but it's not like you're not still on duty for making sure these things are still working and happening. EDIT: For clarity: You can set up a multi-AZ MySQL database instance on AWS, with whatever backup schedule you want, using a single API command. That is decidedly doing a lot of things under the hood, but I don't care--it gets done, and the backups get made to S3, and I don't have to handle it myself. It even (optionally) does minor updates for me and swaps masters automatically while doing them. To me, this is a great example of "boring." Now compare that to setting up and maintaining something similar with SQL Server. It doesn't mean I don't have to secure or backup my MySQL database instance--it's just a whole lot more "boring" in the good way.
leothekim 10y ago
Some interesting thoughts on a similar sentiment: http://mcfunley.com/choose-boring-technology http://mcfunley.com/choose-boring-technology Nice takeaway: "The nice thing about boringness (so constrained) is that the capabilities of these things are well understood. But more importantly, their failure modes are well understood."
pjmlp 10y ago
It also resonates with me. I play with all sorts of programming languages, specially on those long winter nights. When it comes to production code it is all about the Java and .NET stacks, with some C++ only when there is a need to integrate some sort of native library, or call the respective VM APIs. Even then I can usually sort it out with JNA, P/Invoke and RCW.
ohstopitu 10y ago
I personally enjoy the new & fancy. Infact, I try the new stuff because I enjoy trying it out, and the "gotcha" moment with that happens when you understand the stuff. That said, If I had to choose a tech stack for work, I'd choose something that I am comfortable with and something that I know a lot about (compared to the rest of the stuff available) - because in the end, it's not about having new and shiny so I can blog about, but to solve the problem that my company is facing/trying to solve.
- nine_k 10y ago
  There's an important difference: the new and shiny may be something that increases your productivity. The increase may be so big that it outweighs the risks of it not being mature or well-known enough. See Paul Graham's essay on Lisp as a secret weapon. There were a number of now-popular "secret weapons", most way less elegant than Lisp (e.g. Rails), used exactly because they made your product's time to market much shorter. Getting to the market quickly, while an opportunity still exists, is one of the most important problems any company is going to solve. Operational excellence may take a back seat compared to it.
  - ohstopitu 10y ago
    I totally agree! That's why I check out the new stuff in the first place. It's not just "keeping up with hype" as most people say. Generally, new tech comes up with it's own way of doing stuff (which may be exactly what you need to solve your problem).
  - bbcbasic 10y ago
    My counterargument is when rails came out PHP was just as capable of letting you knock stuff up quickly and meeting the business goals for a startup. Where rails excels I think is at shops that need to pump out different websites for different clients so that continually starting over cost is minimised. And Lisp is old tech.
    - nine_k 10y ago
      Rails, like all opinionated frameworks, gives you a great head start for a new project, as long as you follow the prescribed project structure. (It starts to feel worse as you grow and hit the restrictions of the baked-in assumptions.) Lisp is not "old tech"; Lisp is timeless tech. Like, well, math. BTW, Unix is also rather old, but still does remarkably well, and gave a distinct edge to its users since ~1990s when Linux and FreeBSD became viable server platforms.
sklivvz1971 10y ago
Absolutely agree with the article. We do boring stacks at Stack Overflow (we are proudly a ASP.Net MVC/SQL Server shop) and our performance stats are pretty damn good. Our average page is rendered in less than 20ms on cache misses [0] and we do over a billion page views per month with 9 web servers at 5% capacity. [1] Sorry but it does get annoying when people suggest we "improve" our stack with $fancy_new_stack. [0]: https://twitter.com/Nick_Craver/status/790527231600787456 https://twitter.com/Nick_Craver/status/790527231600787456 [1]: http://stackexchange.com/performance http://stackexchange.com/performance
- xeromal 10y ago
  As a lowly .NET dev, thanks for leading the way to making us cool. I'm sure you guys have some fun whitepapers.
- japhyr 10y ago
  How geographically distributed are stack overflow's servers?
  - sklivvz1971 10y ago
    We have two datacenters, one in New York, the other in Denver. Only one is active at any time. We also use Fastly for delivering static assets.
    - pavs 10y ago
      Thanks for dumping CloudFlare.
      - cyberferret 10y ago
        Is CloudFlare no longer the shiny new CDN of the month? If not, could you elucidate a bit more as to why they are not?
        pavs 10y ago
Animats 10y ago
I agree. A site I run: Server status at 2016-10-25 12:07:41 System status: Database up for 419.94 days. It's Python and MariaDB.
- majewsky 10y ago
  So you're not doing any important kernel updates?
tikhonj 10y ago
It all depends on how you define "boring": • If you mean "familiar" then you're right: something you know is better than something you don't. (But it's not the way to learn or expand your horizons.) • If you mean "stable" then the whole thesis is a bit of a tautology—crucially, there's no fundamental contradiction between "new and shiny" and "stable", and "boring" stuff is often also unstable/insecure/bug-prone (think PHP or C). • If you mean "popular" or "mainstream" then you're putting way too much stock in the judgement of crowds. Crowds and fashion are fickle and the popularity of a product is a poor indicator of any intrinsic qualities. I've seen people using all three of these definitions—and linear combinations thereof—when talking about these things. More too, probably. I think it's important to separate them out exactly what you mean by words like "boring" or "practical" when talking about software tools and abstractions to understand exactly what's going on and to communicate clearly.
- owdadithurts 10y ago
  Maybe "stable" was the wrong word. Perhaps "proven stable" would be better. It's not that "new and shiny" can't be stable, it's just that it hasn't proven itself stable yet. It hasn't been around long enough to prove it. So it's more using technology that has over a decade of proven dependability, over something that may or may not be.
  - cutler 10y ago
    Elixir, Clojure and Scala cut across this distinction. They're very new and shiny but built on proven technology. In that sense maybe they're a better bet as they definitely bring something new to the table and help solve hard problems. I think Clojure suffers most from this familiarity bias as I'd argue it's at the top of the excellence tree despite being largely ignored by an industry forever wedded to C# and Java.
    - kod 10y ago
      It's been over 12 years since Scala 1.0. I've been doing Scala full time for 7 years. It's not new and shiny.
hockeybias 10y ago
Agreed!
qwertyuiop924 10y ago
It depends on if you like the boring stack, and also what your normal stack is. If you mostly write ruby, Sinatra or Rails should be your first port of call: they're widely used frameworks in your language. But no, don't go for the zeitgeist for no reason: zeitgiest is tautologically new, and new stuff tends to break a lot.
bbcbasic 10y ago
.NET also suffers from the image problem of the anti micro$oft, anti-IDE, anti-not-open-source sentiment.
- flukus 10y ago
  It's been open source for several years now. It's more open than java, android and many high profile OS projects. They've also decoupled intellisense from the IDE, meaning any text editor like vim can get the same features.
intrasight 10y ago
I've flipped-flopped back and forth several times over the last 15 years on the question of server-side vs. client-side view logic. I literally start each new project with a new technical review and evaluation of this question. I'd have flipped permanently to client-side if the quality and consistency of the JS stacks were of the same quality as the server-side stacks (I use ASP.NET MVC). I know that it has been a rapidly evolving thing and hence the churn. But here's the thing - with software I've come to prefer intelligent design over Darwinian evolution. On the server-side we have intelligent design; on the client we have evolution. On the server, we have stability and a roadmap. On the client we don't. With that said, painting pages on the server to send down to the client just doesn't smell right anymore.
- majewsky 10y ago
  > With that said, painting pages on the server to send down to the client just doesn't smell right anymore. Can you elaborate on that?
  - intrasight 10y ago
    By that I mean that we should have moved cleanly beyond that by now with no regrets. Certainly it comes from my time in the '80s and '90s developing "desktop" software (of course we didn't call it that)on Unix and Windows. There were user interface objects that had behaviour. Once we "got" that HTML and JavaScript could do similar, we make the browser into the new windowing system. But unlike the Windows and Unix desktops of old, which had "official" SDKs and libraries, it was the wild west. Fifteen years later it still is. If fifteen years ago you had said that one starts a new project by running a command-line script that would clutter your project with hundreds or thousands of tiny source files from sources unknown, we would have laughed at the absurdity.
- flukus 10y ago
  I've settled on a halfway point being my ideal. The server will render a "page" but knockout will take over and render the interactive parts before it's visible to the user. Applications then become a collection of tiny single page apps.
draw_down 10y ago
"Boring" meaning "a lack of surprise", sure. "Boring" as an antonym for "what the cool kids like", no. Plenty of unfashionable technologies are that way for reasons.
SadWebDeveloper 10y ago
tl;dr Full JS Stack Engineering sucks.
brhsiao 10y ago
I often hear this sentiment that new languages and frameworks du jour pop up every week, and that past an age a fellow just wants to learn a single reliable stack and collect a weekly paycheck. Am I the only one who just hasn't experienced this feeling? There used to be Rails/Django and jQuery. Now there's Node and React. Both revolve around extremely simple ideas. Spend an afternoon reading the React docs, and you'll know everything you need. Take another afternoon after that and learn Redux. If you have another few afternoons, learn Clojure, and see what the Lisp folks have gotten going with reagent/re-frame. There isn't that much to keep up with. It's the same with complaints about JS having too many transpiled dialects. These dialects make life easier. There are good ideas in them. For example, Livescript is wonderfully concise and elegant, at no cost of readability once you grok Livescript. It makes your code more readable and faster to write. How is this a bad deal? I sometimes wonder if people are just annoyed that they need to learn new paradigms at all. It's not like ours shift at an especially fast rate.
- ASalazarMX 10y ago
  I believe the sentiment is not "wanting to stickg to one thing", but rather "we keep fixing development by adding more layers and complexity".
- munchbunny 10y ago
  I follow your reasoning for the most part, but there's one core problem that inevitably comes up: everything has quirks, and the quirks add up over time. Boring stacks are partly boring because they've been around for a long time, but they are also boring in the sense that they are predictable. The problem is that in any suitably large project, you will inevitably cover enough use cases to run into a library or language's quirks. Browser support issue in this one corner, language ambiguity in this other corner, unsupported arcane combination of theoretically orthogonal functions in yet another corner, and then a slow inner loop in some other corner. Once you've added everything together, you get a big headache. With more mature stacks, it's easier to anticipate these issues because they are well documented all over tutorial materials, knowledge bases, and just professional experience. They've also had time to iterate and address many of the design and polish issues that would slow developers down.
bbcbasic 10y ago
If you are doing a side project you can choose between solving a real problem or learning new tech. It is hard to do both simultaneously in the time that most people give to side projects. Hell its hard even if you are full time. Learning new tech in a side project is a worthy thing to do and I have built some nice little toy Haskell, Elm, JS and Java projects. However I am more productive in my usual C#, so if I wanted to get something done quick e.g. an MVP website, I'd probably that would be the best choice despite the advantages of other languages. E.g. PHP -> cheap shared hosting, easy to deploy, Haskell -> Excellent type system, find most bugs at compile time, etc. One exception is I recently want to scrape the HN Api sequentially with multiple requests at a time, and I found this easier on Node.js than C#, because I could be sure I wouldn't get exceptions saying my threadpool has run out of threads etc. :-)
nstj 10y ago
What a wonderful article. Bravo.
jupp0r 10y ago
There were times when .NET was the new and shiny (it arguably still is with the recent open-sourcing and stuff going on in F#). I wonder if it was back then when the author started to use it :)
- frogfuzion 10y ago
  Nice. I remember when I was begging my manager to switch from our classic ASP/JScript/MS SQL/Java Applet stack to .NET and he refused saying that it was not mature enough. Good Times.
komone 10y ago
Ah yes. The difference between actual requirement and perceived requirement. Worthy statement.
deleted 10y ago
[deleted]
sunstone 10y ago
I totally agree with the philosophy but for me it's Django, python and postgres on ubuntu server.
arthurread 10y ago
I agree. Kind of. You get to choose the kind of problems you work on, and the way you break up your time. If you want to innovate on the infrastructure, if you find that interesting or if worth the gains for the kind of scenarios you work on then go for it. At the same time focusing on solving problems in the programming infrastructure, spinning cycles learning new techniques means you get less time actually solving problems in your actual problem domain. You don't need a $3000 carbon fiber road bike to get to your friends house down the street, no matter how many articles you read about how good that road bike is. I suppose the idea is use the most boring stack that can get the job done.
bootload 10y ago
"Good old C#, SQL Server and a proper boring stack and tool set that I know won't just up and fall over on a Saturday morning and leave me debugging NPM dependencies all weekend instead of bouldering in the forest with the kids." Microsoft tax. Yes you can get alternative C# implementations [0] but SQL Server? Having to deal with "MS Tools" in an era of high quality alternatives? Boring for me would be Perl/Postgres, both in their 20's, solid, reliable, with plenty of quality developers and language support. [0] https://en.wikipedia.org/wiki/C_Sharp_%28programming_language%29#Implementations https://en.wikipedia.org/wiki/C_Sharp_%28programming_languag...
- staticelf 10y ago
  At my last job the backend system was mainly written in Perl, finding developers was nearly impossible. Of course, it may have to do with the fact they paid less than other companies and did not allow remote work.
EugeneOZ 10y ago
MS SQL Server is so awful crap, you can just try any another DB to see that - I can't trust this author after "good old SQL Server". And I don't see nothing except boring oldman grunting in that article. Programmers should always learn and they know it from the beginning of their way.
- fencepost 10y ago
  And yet it meets the key requirement: it's up and running, stable, for years, growing and (presumably) profitable. Sure, they could scrap the whole thing and rewrite it in Grails, and add Rabbit 0.3 to make it run faster, but why scrap a working, stable profitable stack in pursuit of some shiny bauble?
  - EugeneOZ 10y ago
    author is writing about new projects, not about rewriting old ones.
- mrweasel 10y ago
  I never push SQL Server to hard, but it have always been stable and extremely well documented. It's certainly better than MySQL in many respects. Would you mind sharing a bit about how SQL Server has failed you? I would genuinely like to know, maybe there's some use cases where I need to at least be careful about picking SQL Server.
  - EugeneOZ 10y ago
    For example, try to work with UTF-8 strings - concatenate them, compare their parts. And it's just one aspect - there is a lot of them.
dsolin 10y ago
Totally agree, but I remember the (childish) excitement of using the new, shiny, "cool" stuff. And then the satisfaction of snorting at the soon-to-be-released .NET Framework. And not to talk about that Java-rip-off of a language that would come with it!!! Oh those were the days... I am a C#-developer today, but don't tell anyone! ;)
jon49 10y ago
F# is an amazing language on the .NET stack that is strongly/statically typed but will infer many of the types. It has TypeProviders which let you strongly type your external code sources (FSharp.Data.SqlClient is just amazing - statically typed SQL directly in your code!). Unions/Discriminated Unions, units, etc. Much cleaner than C# with all the .NET goodness!

558 points by jasonkester 10y ago

qaq 10y ago

You can have both happiness and an interesting stack a good example of this is Elixir or I would guess F# in the .Net world.

sarreph 10y ago

I've been thinking a lot about this recently. I'm in between jobs and thinking of starting a SAAS on the side in order to support my goal to go backpacking for a few months next year. However, the amount of microservices I'm thinking of putting it all together with means it'll require a decent amount of non-automatable (as far as I can tell) maintenance and attention. This isn't exactly what I want at the back of my mind all the time while travelling... but then again, you can't have all your cake and eat it. Anyone who has a successful hands-off SAAS built on a modern stack care to chip in on ways of mitigating this?

dtien 10y ago
How about don't go with a microservice arch. Nothing wrong with tried and true monolith Django, Rails, or [your favorite stack]. In fact, sounds like this is your first time out, in which case I would absolutely recommend minimizing the headache and complexity and go with a simple monolithic stack. [insert rant about premature optimization] In any case, build your SaaS, go backpacking. Both invaluable experiences.
bensummers 10y ago
Write it as a monolith. If you get to a stage where it needs a bigger server than you can afford, run a profiler on it, and fix up any glaring performance problems. Then if it gets wildly successful and does actually need microservices, then you have the resources to pay for the development & sysadmin overhead. Also by delaying as long as possible, you'd have the maximum information and maximise your chances of getting the split right.
jasonkester 10y ago
Expanding on the "both/and" advice from elsewhere in this thread, I'd recommend saving for the backpacking trip first with a boring-yet-lucrative consulting gig, then building the SaaS product during your downtime on the road. It'll fix your expectations and your finances all in one go. SaaS businesses take at least a year or so to ramp up to the point where they can reliably support you (even on the beach in Cambodia). It'd be a shame to have to cut your trip short because the thing you'd built wasn't immediately successful. With luck, it'll be the thing that finances your second lap around the world three years from now. [edit] And yeah, don't build microservices. Especially for a B2B SaaS. Scaling problems for products with a price tag are things that come with tons of money attached. Use that to scale when and if it becomes a "problem". For now, build a boring Rails app on PostgreSQL or whatever has the least chance of falling over while you're halfway down the Inca Trail.
MikeKusold 10y ago
Organize your microservices as packages, then run it as a monolith. Host it on Heroku. Now you have no ops, and no automation needed. Once your business grows to the point where you need to scale, you can easily split apart your monolith and you can host it on AWS (Heroku makes it easy to migrate your database to AWS).
UK-AL 10y ago
Write it as a monolith, but easily converted to microservices. I find you need a monolith phase anyhow to find out your real microservice boundaries before guessing.
brightball 10y ago
Elixir is a solid solution for this. You essentially write micro services as a monolith that runs on the BEAM VM and naturally spreads across a cluster (https://elixirschool.com/lessons/advanced/umbrella-projects/ https://elixirschool.com/lessons/advanced/umbrella-projects/). It's all message passing without shared memory so whether you're sending something to a different function, process, processor or machine in a different datacenter your code doesn't really care. As a bonus you don't have to define REST/SOAP/Protocol Buffer interfaces for every single microservice you're writing...since it's just function calls. Everything works smoothly and efficiently just like boring Erlang has for decades, with some readability and productivity perks that Elixir gives you. Elixir sounds trendy and new, but it's just modernized Erlang. It's older than Linux.
- amorphid 10y ago
  I <3 actors & immutability. I didn't understand what "easy to reason about" meant until learning Elixir.
  - cutler 10y ago
    Yes, I loved Elixir as soon as I set eyes on it. However, as far as "easy to reason about" goes, Clojure in an Emacs CIDER repl is about as good as it gets.
arikfr 10y ago
There aren't many SaaS services I can think of that can be truly hands-off to the extent that you can backpack with a free mind. Also scaling a SaaS business takes time and significant effort. All of the above is from personal experience. If I were looking for passive income from software I would've looked at desktop software.

milesf 10y ago

This what I like to call "both/and". I like both the old reliable and the new shiny. So often people want things to be "either/or". Either I'm going to use this solution or that one. The key is to know the context of each, and I think this article does a very good job of describing when each ought to be used. He uses the boring reliable stuff on his own things, because he is beholden to no one and does not need to justify his decisions. And he also works with the exciting new stuff with clients, because it is simply easier to sell it to clients who are caught in the Silicon Valley echo chamber. Both/And is like trying to hold a small bird in your hand: too tight and you'll crush the bird and it will die, too loose and it will fly away.

nxc18 10y ago
Its interesting to note that there is an inversion here. You'd think that for one's own enjoyment, the new and shiny would be the natural choice, while dependable and stable long-term would be reserved for people who need dependability and reliability long term (a.k.a. Clients).
- ynniv 10y ago
  There is no inversion: new and shiny is what clients want, boring and dependable is what owners want. In this example he owns the boring products, and builds the shiny ones.
  - gjvc 10y ago
    "new and shiny is what clients want, boring and dependable is what owners want" excellent summary.
- bunderbunder 10y ago
  I think it comes down to how you want to spend your free time. Some folks like to spend it building new things, and don't want to be hampered by having to spend time learning the ins and outs of $fancy_new_thing. Others like to spend it playing with new things, and don't like to be hampered by any technical limitations of $boring_old_thing.

rch 10y ago

In other words: 'When you have the option, use the stack you're most comfortable with'.

bunderbunder 10y ago
It's not just comfort, it's that stuff that's been around the block a few times tends to fall into one of two categories: Stuff that's solid and stable and not very fussy, and stuff that nobody uses anymore because it's a PITA. That makes it pretty easy to make good technology decisions. Newer technology tends, almost by definition, to be very experimental. And experimental means, almost by definition, that some ideas are going to work out and others aren't. Oftentimes it takes a while to figure out which is which. And popularity, even extreme popularity, tends not to be a good proxy for robustness - if anything, it's a source of noise that only makes it harder to figure out what's robust because hype tends to be a pretty darned autoregressive process.
- amorphid 10y ago
  I find Elixir easier than Ruby and Javascript, one you figure the actor model, dialyzer, and reading other people's macros.
- rch 10y ago
  Sure, but longevity alone is an insufficient criterion. There are a few venerable, perfectly adequate, stacks (for lack of a better term) that I would rather not start new projects with. I say this as someone who once had to argue forcefully to start a new project in .Net while it was still in beta.

sdegutis 10y ago

Fully agree. We're moving our work codebase from Clojure to Java. It's true that Java is boring and old and simple. That's what makes it great! Now we can focus 100% of our efforts on the business logic rules. (Granted, sometimes I wish we were using C# instead. But only sometimes.)

ungzd 10y ago
Clojure is real boring stack. No abstract singleton proxy factories, just plain scripting. I have web application in production using plain Ring API, without frameworks. Like good old days of CGI and PHP but more sane.
- edwinnathaniel 10y ago
  > No abstract singleton proxy factories I barely see this in the code that I wrote given that I've been writing Java code for ... 8 years? (unless you're writing Spring framework itself) Can we please drop this?
  - kelnos 10y ago
    > Can we please drop this? I would love to agree with that, but I don't think we can. I've been writing Java (well, more recently Scala) for 14+ years, and I still see otherwise great programmers succumb to Java class-itis.
    - lacampbell 10y ago
      I see a lot of bad C# code, but I don't feel the need to make snide comments about C# whenever I see or hear it mentioned. It's pretty clear to me it's not the languages fault. There's nothing in Java forcing you to make deep class hierarchies or leaky abstractions.
      - kelnos 10y ago
        Nothing that forces you, sure. But when you have a culture following that language for so long that encourages that, and have existing 3rd-party libraries and an ecosystem that makes it easier to do that... well, that's what happens. Not sure about the GP of my original comment, but I'm not trying to be snide; I just see it everywhere, and it really frustrates me. I don't see it with Scala/C++/python/ruby programmers, so what's the common denominator? The language.

bluejekyll 10y ago

> Good old C#, SQL Server and a proper boring stack And? What is the proper boring stack for targeting a browser? The reason React is so popular is because it answers a fundamental problem of application delivery to the browser client. If you're living in C# land that's not always boring either, as soon enough you have a GC nightmare. I agree with everything in this article in principle, but it fails to leave room for innovation, where innovation is necessary. And an MS stack when 80% of the world deploys to Linux on the serverside. You might be stuck in the wrong decade...

rpeden 10y ago
If you're running a small SaaS company, it doesn't matter all that much what 80% of the world is doing. I used to feel the same way you do. My apps were all Ruby or Java, usually with Postgres, deployed on Linux. My past couple of employers, though, have used C# and SQL Server running on Windows Server. And they've both been able to handle heavy workloads without using a huge amount of resources. I'd think twice about using SQL Server if I were launching a small SaaS app due to licensing costs. But the extra cost of a Windows VM wouldn't hurt much if I had more than a couple of users. And I know from personal observation that a relatively boring Windows/IIS/.NET stack would handle the workload of my SaaS app without breaking a sweat. And there's no reason you couldn't mix in React on the front end. I haven't run into any noticeable GC issues even while running heavy workloads, but I could see it being an issue depending on the type of work you do. That's not to say you shouldn't deploy a cutting edge web stack on Linux or the BSD of your choice. You can certainly be successful that way too. Perhaps a balance is best: use boring, battle tested technology where you can, and use the cutting edge tech in places where it will give you a competitive advantage.
vlunkr 10y ago
I like React, but it's delusional to think you can't target a browser without it. I mean, we lived without front end frameworks for a loong time before that.
- bluejekyll 10y ago
  I'm not saying you can't target a browser without it, I'm saying it answers a development problem of having rich applications built on the clientside.

ungzd 10y ago

Maybe yes, when you work at bank, change 1 line of code per month, documenting this change in 10 Word documents, most of time drinking coffee and sleeping during Powerpoint presentations with 1000 attendees.

crpatino 10y ago
You are not being paid to change 1 line of code per month. You are being paid to be a living repository of institutional knowledge: so you (can) know (in a finite, bounded time) what line to change in order to achieve the business requirement, and what dozen-or-so Word documents you need to read in order to confirm which unintended consequences may result of that change. That said, sleeping during massive presentations will hinder your abilities as a living repository... so, hang in there and keep pouring-in the coffee.

lmm 10y ago

Low maintenance is important, but so is functionality. It's frustrating to have to fix code that was working and gets broken by some update, but it's even more frustrating to have to copy/paste code because your language doesn't have the abstraction facilities that let you factor out the commonality.

edwinnathaniel 10y ago
> but it's even more frustrating to have to copy/paste code because your language doesn't have the abstraction facilities that let you factor out commonality. I find this statement to be less of a problem in many modern programming languages (or greatly exaggerated by a specific language fan when comparing his/her preferred tools vs "the other languages).
- lmm 10y ago
  I think in higher-kinded types these days, and can't stand to use a language without them (where I necessarily end up copy-pasting). There are plenty of modern languages without that. I've only had to copy-paste code because of Scala's lack of support for polykinded code a few times, but it was very frustrating every time. Hardly any languages, even modern ones, support that.
UweSchmidt 10y ago
What language doesn't have abstraction facilities to factor out commonality? Even assembler has macros :-)
- lmm 10y ago
  Misspoke; I meant "don't let you factor out that particular piece of commonality".
crpatino 10y ago
If you think copy&paste is an option at all, I agree. If you are to rely on somebody else's work, better make it work they have put an actual effort in getting right, for which they have some stakes. Doing "boring stack" implies you actually know what you are doing, though.

mixmastamyk 10y ago

I agree in general but why would you use Windows/SQLSrv for internet-based products? I'm fine with it on the desktop, but the extra costs and time devoted to things like activation are a non-starter as far as I'm concerned. I believe they finally have ssh and package mgrs available, but don't you still have to install them manually? There's plenty of boring stacks on Unix that are free, in both senses of the word.

smacktoward 10y ago
Because it's what you already know? Teaching yourself *nix from scratch isn't free. Because there's some other piece of software you want to use that requires it? (Lots of people seem to like MS SQL Server, for example.)
wvenable 10y ago
Activation? I do development in both stacks, and there are pros and cons to each. For Windows, the biggest con is really cost. If you're comfortable with both stacks the difference in setup/maintenance isn't very different. However, the author makes a good argument about boring stacks in general. Your boring Linux stack will be much easier to maintain than something on bleeding edge.
rpeden 10y ago
Because it performs well, and the cost of Windows licenses ends up being a rounding error if you have paying users. I've administered Linux boxes for years, and while I enjoy it I find Windows Server more enjoyable to work with in many cases. SQL Server licensing is another story. It is expensive, but I've also seen it handle heavy workloads on modest hardware without complaining. Though I don't doubt the same is true for Postgres and MySQL/MariaDB/Percona. From what I've seen, the constellation of reporting and BI tools around SQL Server are what make it appealing to enterprises regardless of cost.
- bad_user 10y ago
  Windows being a rounding error is kind of a myth perpetuated by people that haven't been in the position to buy Windows licenses for a company. First of all most software developers are not working in the consumer space. And for B2B you often get asked to have an on-premises option, either because the company doesn't trust you with their data, or because non-stop Internet connectivity can be a problem. And when deploying on-premises, the cost of the Windows licenses do matter a lot. If the clients are just web browsers then you can save the company a lot of money, since the clients can be just terminals powered by whatever you can get your hands on. But if you assume Windows clients, well, the costs can be huge. And on the server side, remote maintenance is way cheaper with Linux boxes, because well, you can control anything on a remote Linux machine, securely, reliably and for free. Add to that the licensing cost of Windows, which isn't cheap because you can't run a server on Home edition. Basically if your solution assumes Windows in any way on the customer's side, you're just adding unwanted cost that could have been your profit. And SQL Server is simply unjustifiable.

dahdum 10y ago

"It seems like on a lot of stacks, keeping the server alive, patched and serving webpages is a part-time job in itself. In my world, that's Windows Update's job." I imagine the Linux alternative of this would be Debian with unattended-upgrades and a PHP app.

edwinnathaniel 10y ago
PHP/Java/Perl. Python used to be in the list before every body in the neighbor wrote their own framework and/or different flavors of library that solve the same problem :p.
icebraining 10y ago
Sounds about right. I run Tiny Tiny RSS with Postgres and Nginx on Debian Stable and I can't remember the last time I've had to spend time administering it. (I do update TTRSS itself manually, but since it's behind Nginx's basic auth, I don't feel rushed to plug security holes). The truth is, as shown by data, that downtimes is usually caused by developers, not stuff crashing by itself.

libeclipse 10y ago

This is how I feel. I have friends that are always going on about all the latest "best practices" and cool hipster stuff like docker swarms and microservices. Meanwhile I've kept my own projects using boring old (or rather tried and tested) technologies and languages like python. I don't like it when people are recommending new buzz words every week.

matt_wulfeck 10y ago
Unfortunately the new buzz words of today are the boring stacks of tomorrow. I would say that containers represent a greater leap forward in thinking than a new programming language. Like it or not your future applications will run in a linux container.
- crpatino 10y ago
  It is still worth it to delay adoption by a year or two. By then, early adopters have already stepped on most mines, flaky fads have crashed and burned, and the real winners of next generation stack-wars will have coalesced around something reseabling sustainable best practices.
  - matt_wulfeck 10y ago
    I agree. Letting things shake out is an important part of not losing your hair. At the very least you come into an ecosystem with mature third-party libraries.
    - jandrese 10y ago
      And documentation, or at least answers on Stackexchange. Documentation often lags behind on these new projects, especially when they're in a state of flux and you can easily find yourself pulling your hair out because the docs are for two versions ago and wrong now.
  - nickpsecurity 10y ago
    What you said was standard practice for savvy buyers of Windows for around a decade. We always told people, "Just wait till at least SP1 to buy it. You won't regret being a late adopter." We never did regret it.

jsingleton 10y ago

I really like C# and .NET as a stack, just like the OP. It may not be cool but it works well and they are good skills to have for stable employment prospects. The new .NET Core stuff is looking very promising too. I really hope it takes off, and not just because I have a book out on it :).

aswanson 10y ago
On top of that, it has a powerful, well-documented IDE and support community. It is what it is. I love to experiment with new stacks and paradigms but if I want to Get Shit Done, nine times out of 10 Im going with older tools.

apolymath 10y ago

omg this guy is on spot. My day job is Magento (hell), but I am absolutely in love with boring ol' C#, along with the new ASP.NET Core framework & Kestrel web server. All of my side projects are built using C#, and I don't use jQuery or Angular or React or Reactive. I use plain old vanilla javascript, because I care about zero HTTP requests & zero bloat & zero BS.

UK-AL 10y ago
Applications that don't rely on large js frameworks, tend to feel snappier as well.
- cle 10y ago
  They also tend to turn into huge messy hairballs after years of developers and new business use cases. Not that these are use cases for personal projects, but standardized frameworks are valuable for large teams with lots of changing use cases and long-term maintenance requirements.
  - mattnewton 10y ago
    I've seen plenty of Ember apps succumb to the same syndrome- the problem is the developers, who are either incompetent or contractors who care only about the deadline before them. I don't think a framework is a magic cure for bad developers, though maybe because you wrote less code to start it probably does take longer to get to spaghetti hell.
  - tboyd47 10y ago
    It's usually not so bad if you can just keep the amount of client-side code down.
  - ksk 10y ago
    I don't see any long term stability and support in any JS framework. They seem to pop in and out of existence at a fairly rapid pace. What examples do you have of long-term projects that use those frameworks?

sly010 10y ago

Agree. Things like Docker and microservices architecture are solutions for problem you have only if you are playing with more "interesting" stacks.

UK-AL 10y ago
Tbh we use an NServiceBus(.net) microservice stack, and it's been pretty boring and uneventful for us.

drather19 10y ago

I like the point about building systems that take care of themselves and are largely hands-free. I'd say that applies regardless of platform (or "shininess"), though. The author has clearly internalized one of the more important lessons in engineering in terms of designing for maintainability (with an ultimate goal of zero/low-effort maintenance and/or extension). I'm not sure the platform itself is as important to achieving this goal so much as the decision-making ability of the engineers themselves, though. Maybe a tendency to pick shiny because of shiny is just a way that poor decision-making surfaces? However, I don't see a problem picking an appropriate solution that happens to be shiny. Anyways, kudos for sharing the wisdom.

elliotec 10y ago

This is my feeling about Rails. I've created several Rails apps that delighted the customer, and most have required literally zero maintenance after years of use. Sprinkle in a bit of jQuery and you have an app that is stronger and just as fancy-feeling as a mess of a massive client-side app.

cutler 10y ago
I think the improvements to turbolinks in Rails 5 make pjax more of an option now. Also, for scaling remember it's not the end of the road for Rails when you're running out of processes to keep up with requests. JRuby 9000 has been gathering a lot of momentum recently and promises huge performance gains when Truffle and Graal kick in. Migrating a Rails app to JRuby is not that difficult.

josep2 10y ago

This is a refreshing take, although maybe extended a bit too far. It seems like this kind of thinking is mostly in the real of software on the web and not necessarily on the systems side of things.

matchagaucho 10y ago

C# and SQL I might agree with. But ASP.NET and MVC = stable? All the hidden view state and POST backs to re-render the UI... terribly difficult to troubleshoot and support in my experience.

UK-AL 10y ago
That's ASP.Net WebForms which is basically very old and legacy.
- pjmlp 10y ago
  I wish. Even this year I was getting some SiteCore requests, which I didn't accept, but version 6 was largely built on top of forms. I haven't bothered with it since version 6, so I don't know how well it has moved into MVC world.
  - yareally 10y ago
    Seconded. Sadly, our tech stack at work still includes some webforms cruft and I have a few friends at other companies that also still have to deal with them. Could be worse I guess...I know someone that still has to put up with classic ASP. Thankfully I work with backend stuff at my job currently or I'd probably go crazy dealing with a mishmash of mvc and web forms. Webforms are not super easy to get rid of if you weren't careful on how you coupled to them, so I think some code is still being added to ours.
  - flukus 10y ago
    Same with sharepoint, although apparently that supports MVC now too.
yareally 10y ago
> "All the hidden view state and POST backs to re-render the UI... terribly difficult to troubleshoot and support in my experience." You're confusing webforms (with viewstates) and .net MVC, which is stateless. http://stackoverflow.com/questions/23623229/what-is-the-equivalent-of-viewstate-in-asp-net-mvc http://stackoverflow.com/questions/23623229/what-is-the-equi...

rpeden 10y ago

Jeff Atwood made similar points in The Magpie Developer: https://blog.codinghorror.com/the-magpie-developer/ https://blog.codinghorror.com/the-magpie-developer/ and Why Ruby?: https://blog.codinghorror.com/why-ruby/ https://blog.codinghorror.com/why-ruby/ Not that chasing after the latest and greatest is always a bad thing, but sometimes existing (and relatively boring) tools are the best ones for the job at hand.

majewsky 10y ago
Not related to the article, but I couldn't help but chuckle at this part from the "Why Ruby" post: > It is just not a native part of the Microsoft .NET culture to make things open source
zengid 10y ago
From "why ruby": >Ruby isn't cool any more. Yeah, you heard me. It's not cool to write Ruby code any more. All the cool people moved on to slinging Scala and Node.js years ago. Our project isn't cool, it's just a bunch of boring old Ruby code. Personally, I'm thrilled that Ruby is now mature enough that the community no longer needs to bother with the pretense of being the coolest kid on the block. This is my feeling right now. Nobody is yelling about Ruby so I can take my time and enjoy learning it at my own pace.

deleted 10y ago

[deleted]

clifanatic 10y ago

Well, I don't know if "boring" is the word I'd use, but I like _transparent_ stacks: if I make a mistake, it tells me where I made a mistake in a way that I can interpret. All of the "boring" stacks have this property.

jimbokun 10y ago
I think this is the biggest selling point for Functional Programming. You know given these inputs, you will always get the same output. Even if not using a Functional Programming language, it is good practice to write your code to follow this principle whenever possible. I think this is what mocks and unit tests try to achieve, creating a scenario where given certain inputs, you know what the output will be.
- nikanj 10y ago
  From what I've seen, functional programming doesn't really excel at error messages
  - edgyswingset 10y ago
    Sure it can - here's an example of an error message added to F# which suggests valid names for Record labels when you've typed an incorrect one: https://github.com/Microsoft/visualfsharp/pull/1102 https://github.com/Microsoft/visualfsharp/pull/1102 Don't confuse correlation (some functional programming languages out there don't have good error messages) with causation (functional programming languages don't excel at good error messages).
    - reitanqild 10y ago
      Elm is also said to be a good example. Haven't gotten around to really test it after hello world though but what I read was somewhat convincing.
      - 616c 10y ago

moduspwnens14 10y ago

It's a great point--it just seems arbitrary to draw the line in the sand of having a "boring stack" that consists of SQL Server and C#. I mean, that, as a minimum, means you're running and maintaining a Windows server, along with antivirus, backups for the OS, and backups for the database. Any time Windows updates come along, your service will be unavailable. Every couple of years, you'll need to buy a new license, upgrade Windows, and make sure everything comes up smoothly. This likely will involve fixing and troubleshooting some issues. You'll need to have some monitoring set up to make sure you don't end up running out of disk space on Saturday morning. Or maybe you have more than one Windows server (to avoid downtime from a single server), but that makes your stack decidedly less "boring." Now you're dealing with at least a load balancer and making SQL Server redundant. I mean, I guess it's more boring than chasing the latest front-end reinvention or maintaining MongoDB, but there's some room for improvement here, clearly. Containerized deployments (via Docker or a "serverless" architecture) might be able to help.

bunderbunder 10y ago
> I mean, that, as a minimum, means you're running and maintaining a Windows server, along with antivirus, backups for the OS, and backups for the database. By contrast, if you're on the LAMP stack then you won't need a Linux box, and since you don't have a server you definitely won't need to secure it or back it up. It'll all just run on clouds or something, I guess.
- moduspwnens14 10y ago
  No, the point is relative to being containerized, where you're deciding ahead of time what needs to be backed up (outside the container) and what doesn't. This leads to backups and restores being easier and more "boring." It's also counter to one of themes of the post, which suggests by choosing this boring stack, he can just leave it alone for months at a time without touching it (presumably relative to other stacks). You can do that--but it's not like you're not still on duty for making sure these things are still working and happening. EDIT: For clarity: You can set up a multi-AZ MySQL database instance on AWS, with whatever backup schedule you want, using a single API command. That is decidedly doing a lot of things under the hood, but I don't care--it gets done, and the backups get made to S3, and I don't have to handle it myself. It even (optionally) does minor updates for me and swaps masters automatically while doing them. To me, this is a great example of "boring." Now compare that to setting up and maintaining something similar with SQL Server. It doesn't mean I don't have to secure or backup my MySQL database instance--it's just a whole lot more "boring" in the good way.

leothekim 10y ago

Some interesting thoughts on a similar sentiment: http://mcfunley.com/choose-boring-technology http://mcfunley.com/choose-boring-technology Nice takeaway: "The nice thing about boringness (so constrained) is that the capabilities of these things are well understood. But more importantly, their failure modes are well understood."

pjmlp 10y ago

It also resonates with me. I play with all sorts of programming languages, specially on those long winter nights. When it comes to production code it is all about the Java and .NET stacks, with some C++ only when there is a need to integrate some sort of native library, or call the respective VM APIs. Even then I can usually sort it out with JNA, P/Invoke and RCW.

ohstopitu 10y ago

I personally enjoy the new & fancy. Infact, I try the new stuff because I enjoy trying it out, and the "gotcha" moment with that happens when you understand the stuff. That said, If I had to choose a tech stack for work, I'd choose something that I am comfortable with and something that I know a lot about (compared to the rest of the stuff available) - because in the end, it's not about having new and shiny so I can blog about, but to solve the problem that my company is facing/trying to solve.

nine_k 10y ago
There's an important difference: the new and shiny may be something that increases your productivity. The increase may be so big that it outweighs the risks of it not being mature or well-known enough. See Paul Graham's essay on Lisp as a secret weapon. There were a number of now-popular "secret weapons", most way less elegant than Lisp (e.g. Rails), used exactly because they made your product's time to market much shorter. Getting to the market quickly, while an opportunity still exists, is one of the most important problems any company is going to solve. Operational excellence may take a back seat compared to it.
- ohstopitu 10y ago
  I totally agree! That's why I check out the new stuff in the first place. It's not just "keeping up with hype" as most people say. Generally, new tech comes up with it's own way of doing stuff (which may be exactly what you need to solve your problem).
- bbcbasic 10y ago
  My counterargument is when rails came out PHP was just as capable of letting you knock stuff up quickly and meeting the business goals for a startup. Where rails excels I think is at shops that need to pump out different websites for different clients so that continually starting over cost is minimised. And Lisp is old tech.
  - nine_k 10y ago
    Rails, like all opinionated frameworks, gives you a great head start for a new project, as long as you follow the prescribed project structure. (It starts to feel worse as you grow and hit the restrictions of the baked-in assumptions.) Lisp is not "old tech"; Lisp is timeless tech. Like, well, math. BTW, Unix is also rather old, but still does remarkably well, and gave a distinct edge to its users since ~1990s when Linux and FreeBSD became viable server platforms.

sklivvz1971 10y ago

Absolutely agree with the article. We do boring stacks at Stack Overflow (we are proudly a ASP.Net MVC/SQL Server shop) and our performance stats are pretty damn good. Our average page is rendered in less than 20ms on cache misses [0] and we do over a billion page views per month with 9 web servers at 5% capacity. [1] Sorry but it does get annoying when people suggest we "improve" our stack with $fancy_new_stack. [0]: https://twitter.com/Nick_Craver/status/790527231600787456 https://twitter.com/Nick_Craver/status/790527231600787456 [1]: http://stackexchange.com/performance http://stackexchange.com/performance

xeromal 10y ago
As a lowly .NET dev, thanks for leading the way to making us cool. I'm sure you guys have some fun whitepapers.
japhyr 10y ago
How geographically distributed are stack overflow's servers?
- sklivvz1971 10y ago
  We have two datacenters, one in New York, the other in Denver. Only one is active at any time. We also use Fastly for delivering static assets.
  - pavs 10y ago
    Thanks for dumping CloudFlare.
    - cyberferret 10y ago
      Is CloudFlare no longer the shiny new CDN of the month? If not, could you elucidate a bit more as to why they are not?
      - pavs 10y ago

Animats 10y ago

I agree. A site I run: Server status at 2016-10-25 12:07:41 System status: Database up for 419.94 days. It's Python and MariaDB.

majewsky 10y ago
So you're not doing any important kernel updates?

tikhonj 10y ago

It all depends on how you define "boring": • If you mean "familiar" then you're right: something you know is better than something you don't. (But it's not the way to learn or expand your horizons.) • If you mean "stable" then the whole thesis is a bit of a tautology—crucially, there's no fundamental contradiction between "new and shiny" and "stable", and "boring" stuff is often also unstable/insecure/bug-prone (think PHP or C). • If you mean "popular" or "mainstream" then you're putting way too much stock in the judgement of crowds. Crowds and fashion are fickle and the popularity of a product is a poor indicator of any intrinsic qualities. I've seen people using all three of these definitions—and linear combinations thereof—when talking about these things. More too, probably. I think it's important to separate them out exactly what you mean by words like "boring" or "practical" when talking about software tools and abstractions to understand exactly what's going on and to communicate clearly.

owdadithurts 10y ago
Maybe "stable" was the wrong word. Perhaps "proven stable" would be better. It's not that "new and shiny" can't be stable, it's just that it hasn't proven itself stable yet. It hasn't been around long enough to prove it. So it's more using technology that has over a decade of proven dependability, over something that may or may not be.
- cutler 10y ago
  Elixir, Clojure and Scala cut across this distinction. They're very new and shiny but built on proven technology. In that sense maybe they're a better bet as they definitely bring something new to the table and help solve hard problems. I think Clojure suffers most from this familiarity bias as I'd argue it's at the top of the excellence tree despite being largely ignored by an industry forever wedded to C# and Java.
  - kod 10y ago
    It's been over 12 years since Scala 1.0. I've been doing Scala full time for 7 years. It's not new and shiny.

hockeybias 10y ago

Agreed!

qwertyuiop924 10y ago

It depends on if you like the boring stack, and also what your normal stack is. If you mostly write ruby, Sinatra or Rails should be your first port of call: they're widely used frameworks in your language. But no, don't go for the zeitgeist for no reason: zeitgiest is tautologically new, and new stuff tends to break a lot.

bbcbasic 10y ago

.NET also suffers from the image problem of the anti micro$oft, anti-IDE, anti-not-open-source sentiment.

flukus 10y ago
It's been open source for several years now. It's more open than java, android and many high profile OS projects. They've also decoupled intellisense from the IDE, meaning any text editor like vim can get the same features.

intrasight 10y ago

I've flipped-flopped back and forth several times over the last 15 years on the question of server-side vs. client-side view logic. I literally start each new project with a new technical review and evaluation of this question. I'd have flipped permanently to client-side if the quality and consistency of the JS stacks were of the same quality as the server-side stacks (I use ASP.NET MVC). I know that it has been a rapidly evolving thing and hence the churn. But here's the thing - with software I've come to prefer intelligent design over Darwinian evolution. On the server-side we have intelligent design; on the client we have evolution. On the server, we have stability and a roadmap. On the client we don't. With that said, painting pages on the server to send down to the client just doesn't smell right anymore.

majewsky 10y ago
> With that said, painting pages on the server to send down to the client just doesn't smell right anymore. Can you elaborate on that?
- intrasight 10y ago
  By that I mean that we should have moved cleanly beyond that by now with no regrets. Certainly it comes from my time in the '80s and '90s developing "desktop" software (of course we didn't call it that)on Unix and Windows. There were user interface objects that had behaviour. Once we "got" that HTML and JavaScript could do similar, we make the browser into the new windowing system. But unlike the Windows and Unix desktops of old, which had "official" SDKs and libraries, it was the wild west. Fifteen years later it still is. If fifteen years ago you had said that one starts a new project by running a command-line script that would clutter your project with hundreds or thousands of tiny source files from sources unknown, we would have laughed at the absurdity.
flukus 10y ago
I've settled on a halfway point being my ideal. The server will render a "page" but knockout will take over and render the interactive parts before it's visible to the user. Applications then become a collection of tiny single page apps.

draw_down 10y ago

"Boring" meaning "a lack of surprise", sure. "Boring" as an antonym for "what the cool kids like", no. Plenty of unfashionable technologies are that way for reasons.

SadWebDeveloper 10y ago

tl;dr Full JS Stack Engineering sucks.

brhsiao 10y ago

I often hear this sentiment that new languages and frameworks du jour pop up every week, and that past an age a fellow just wants to learn a single reliable stack and collect a weekly paycheck. Am I the only one who just hasn't experienced this feeling? There used to be Rails/Django and jQuery. Now there's Node and React. Both revolve around extremely simple ideas. Spend an afternoon reading the React docs, and you'll know everything you need. Take another afternoon after that and learn Redux. If you have another few afternoons, learn Clojure, and see what the Lisp folks have gotten going with reagent/re-frame. There isn't that much to keep up with. It's the same with complaints about JS having too many transpiled dialects. These dialects make life easier. There are good ideas in them. For example, Livescript is wonderfully concise and elegant, at no cost of readability once you grok Livescript. It makes your code more readable and faster to write. How is this a bad deal? I sometimes wonder if people are just annoyed that they need to learn new paradigms at all. It's not like ours shift at an especially fast rate.

ASalazarMX 10y ago
I believe the sentiment is not "wanting to stickg to one thing", but rather "we keep fixing development by adding more layers and complexity".
munchbunny 10y ago
I follow your reasoning for the most part, but there's one core problem that inevitably comes up: everything has quirks, and the quirks add up over time. Boring stacks are partly boring because they've been around for a long time, but they are also boring in the sense that they are predictable. The problem is that in any suitably large project, you will inevitably cover enough use cases to run into a library or language's quirks. Browser support issue in this one corner, language ambiguity in this other corner, unsupported arcane combination of theoretically orthogonal functions in yet another corner, and then a slow inner loop in some other corner. Once you've added everything together, you get a big headache. With more mature stacks, it's easier to anticipate these issues because they are well documented all over tutorial materials, knowledge bases, and just professional experience. They've also had time to iterate and address many of the design and polish issues that would slow developers down.

bbcbasic 10y ago

If you are doing a side project you can choose between solving a real problem or learning new tech. It is hard to do both simultaneously in the time that most people give to side projects. Hell its hard even if you are full time. Learning new tech in a side project is a worthy thing to do and I have built some nice little toy Haskell, Elm, JS and Java projects. However I am more productive in my usual C#, so if I wanted to get something done quick e.g. an MVP website, I'd probably that would be the best choice despite the advantages of other languages. E.g. PHP -> cheap shared hosting, easy to deploy, Haskell -> Excellent type system, find most bugs at compile time, etc. One exception is I recently want to scrape the HN Api sequentially with multiple requests at a time, and I found this easier on Node.js than C#, because I could be sure I wouldn't get exceptions saying my threadpool has run out of threads etc. :-)

nstj 10y ago

What a wonderful article. Bravo.

jupp0r 10y ago

There were times when .NET was the new and shiny (it arguably still is with the recent open-sourcing and stuff going on in F#). I wonder if it was back then when the author started to use it :)

frogfuzion 10y ago
Nice. I remember when I was begging my manager to switch from our classic ASP/JScript/MS SQL/Java Applet stack to .NET and he refused saying that it was not mature enough. Good Times.

komone 10y ago

Ah yes. The difference between actual requirement and perceived requirement. Worthy statement.

deleted 10y ago

[deleted]

sunstone 10y ago

I totally agree with the philosophy but for me it's Django, python and postgres on ubuntu server.

arthurread 10y ago

I agree. Kind of. You get to choose the kind of problems you work on, and the way you break up your time. If you want to innovate on the infrastructure, if you find that interesting or if worth the gains for the kind of scenarios you work on then go for it. At the same time focusing on solving problems in the programming infrastructure, spinning cycles learning new techniques means you get less time actually solving problems in your actual problem domain. You don't need a $3000 carbon fiber road bike to get to your friends house down the street, no matter how many articles you read about how good that road bike is. I suppose the idea is use the most boring stack that can get the job done.

bootload 10y ago

"Good old C#, SQL Server and a proper boring stack and tool set that I know won't just up and fall over on a Saturday morning and leave me debugging NPM dependencies all weekend instead of bouldering in the forest with the kids." Microsoft tax. Yes you can get alternative C# implementations [0] but SQL Server? Having to deal with "MS Tools" in an era of high quality alternatives? Boring for me would be Perl/Postgres, both in their 20's, solid, reliable, with plenty of quality developers and language support. [0] https://en.wikipedia.org/wiki/C_Sharp_%28programming_language%29#Implementations https://en.wikipedia.org/wiki/C_Sharp_%28programming_languag...

staticelf 10y ago
At my last job the backend system was mainly written in Perl, finding developers was nearly impossible. Of course, it may have to do with the fact they paid less than other companies and did not allow remote work.

EugeneOZ 10y ago

MS SQL Server is so awful crap, you can just try any another DB to see that - I can't trust this author after "good old SQL Server". And I don't see nothing except boring oldman grunting in that article. Programmers should always learn and they know it from the beginning of their way.

fencepost 10y ago
And yet it meets the key requirement: it's up and running, stable, for years, growing and (presumably) profitable. Sure, they could scrap the whole thing and rewrite it in Grails, and add Rabbit 0.3 to make it run faster, but why scrap a working, stable profitable stack in pursuit of some shiny bauble?
- EugeneOZ 10y ago
  author is writing about new projects, not about rewriting old ones.
mrweasel 10y ago
I never push SQL Server to hard, but it have always been stable and extremely well documented. It's certainly better than MySQL in many respects. Would you mind sharing a bit about how SQL Server has failed you? I would genuinely like to know, maybe there's some use cases where I need to at least be careful about picking SQL Server.
- EugeneOZ 10y ago
  For example, try to work with UTF-8 strings - concatenate them, compare their parts. And it's just one aspect - there is a lot of them.

dsolin 10y ago

Totally agree, but I remember the (childish) excitement of using the new, shiny, "cool" stuff. And then the satisfaction of snorting at the soon-to-be-released .NET Framework. And not to talk about that Java-rip-off of a language that would come with it!!! Oh those were the days... I am a C#-developer today, but don't tell anyone! ;)

jon49 10y ago

F# is an amazing language on the .NET stack that is strongly/statically typed but will infer many of the types. It has TypeProviders which let you strongly type your external code sources (FSharp.Data.SqlClient is just amazing - statically typed SQL directly in your code!). Unions/Discriminated Unions, units, etc. Much cleaner than C# with all the .NET goodness!