The “Boring Software” manifesto | Hacker News Reader

The “Boring Software” manifesto

tqdev.com

72 pointsamanzi58 comments

This reads as "get off my lawn" with a lot more words, but only because of a couple of things. "built exclusively with popular and proven tools." You might as well say, "built exclusively by developers with vast industry experience". At some point, it becomes self-defeating, as tools don't spring into existence full of popularity and history.

"page reloads vs. single page applications" - I've worked with plenty of "page reloads" frameworks that were at least as complex as their SPA counterparts. I get that you don't like Javascript, but seriously, SPA is proven and popular at this point too.

I think the idea is not to use experimental technology at work. Go ahead and use a new sexy programming language or library that may be entirely defunct in 2 years on your own time, but don't saddle a company with that and think you're good at your job.

The dude is handwringing about NoSQL in 2018. Something like Cassandra is no longer "experimental technology." It is a well-understood technology with well-understood requirements (and they are high, that's why you do a business analysis to make sure they make sense) that happens to be non-relational.

He is handwringing about single-page applications. SPAs have been kicking around for, what, a decade? Let's be real--in this article the single-page application complaint is a proxy for "I don't like JavaScript" and he's entitled to that opinion but it is certainly not "experimental"; JavaScript is not going anywhere, it is well-understood both in browser and on the server, and the libraries and ecosystem are not going anywhere either--if Facebook died tomorrow there would still be React jobs in 2023.

There are parts of current software development that really, really suck. The author does not capture them; this is "new things are scary" complaining and very little more.

> SPAs have been kicking around for, what, a decade?

Only with big players: facebook, gmail, etc.

Small crew SPA usually suck big time precisely because there is not django/ror/etc equivalent for SPA. So people write it by hand. And they don't all have the talent pool and money the GAFAs have.

Small crew web apps usually suck, too. I have yet to see React (not to exclude Vue etc., React is what I use) make a nontrivial one worse than it otherwise would be, if only because it forces some semblance of separation of concerns upon the developer.

(And, speaking personally, my now-standard stack of TypeScript/Express/TypeORM/tsoa provides a level of architectural enforcement I've only really gotten previously on the JVM, but with significantly less mucking around with my runtime.)

It would be pretty hard to mess up a hackernews clone.

A HN clone SPA though...

First, let's see if they can get code splitting right to not make it loads 3mo/page.

Then if they can choose a stack that doesn't kill navigation.

Also, let's see how long it takes both team to come up with the same result.

My money is on the static stack. Just the registration without a good framework is plenty of fun.

Not that you can't make a SPA with an old school framework. But for some reason, SPA lovers will often go full nodejs as well, which is basically 1000 of libs you have to hand picks and fuse together.

I work on more and more SPA every day. It's always the same deal: the cost is higher, and it needs smarter devs.

Bottom line: do one when it has a good added value for your users.

It's actually worse than you're saying.

NoSQL databases have been around since the 60s [1], and the term was created in 1998. Two decades ago. Is the author of this manifesto saying that they'll only work with tech from the 50s? Or is the 80s good enough? The 90s clearly isn't.

In fact, Ajax has _also_ been around for two decades; 1998 was a big year for the web, apparently. The Outlook Web App (a major milestone in SPAs) was created in 2000, 18 years ago.

This "manifesto" is nothing more than "I choose to bury my head in the sand and use outdated tech and ignore the state of the art!"

[1] https://en.wikipedia.org/wiki/NoSQL

I'm aware on both counts--I was more looking at it from the standpoint of common acceptance. Cassandra was first released in 2008 and became pretty manageable not too long after that. OWA was 1998 and GMail was 2004, but the tools were pretty grungy and hard to get into for awhile. I'd say that they didn't become really legitimately decent until Backbone (late 2010), but there were workable ones for a couple years before that.

Just saying that both SPAs and NoSQL have had _more_ than enough time to mature. It's not like they both were invented a decade ago; they were a decade _mature_ a decade ago.

They seem to have left it intentionally pretty vague in order for people to fill in these sorts of gaps. If they meant "don't use experimental technology at work" then they should say that.

If they are trying to imply it by giving examples of technologies that are hardly new or experimental, then that's even more cause for being explicit.

They say they're sick of "hyped and volatile technologies" which I think is the same thing as experimental technologies.

Perhaps they could have picked more black-and-white examples like blockchain, so many dead javascript libraries, so many rebuilds of existing technologies. But I happen to agree with their examples largely.

Full disclosure: I work on a language that is almost by definition niche, and benefit from its adoption.

I think workplaces really, really should be using newer/"sexier" programming languages and libraries, but not as a blanket approach. People should be allowed to experiment and try new things, especially for projects or parts of projects that are new and exciting. This shouldn't be in lieu of existing and well-known technology.

I was working on a SPA 12 years ago, and even then it couldn't be considered "groundbreaking" - NetVibes and a few others had blazed that ground at least a couple of years before that.

The date I use for SPAs entering the mainstream is 2004-04-01 when gmail was released.

Yeah, pageload based frameworks and design strategies are a whole mess of complexity that SPAs actually avoid completely. That said, one has to be careful to do reasonable things with the URL bar, so bookmarking, etc works as users expect. This adds some of the complexity back, but not nearly as much as page-load based forms can. The SPA design pattern also creates a nice separation of concerns between the front-end and back-end services. It really is much simpler, conceptually and practically.

Honestly, if you're going to use browser JavaScript, I don't see why you wouldn't do an SPA.

Cookies and injection attacks vs Local storage

Fat server sessions vs fat client sessions

Forms and CSRF vs XHR JSON

Let's not pretend that web tech has somehow been Nirvana at any point in the past.

No but it's been automated very well, battle tested, and plays well with the browser.

While I still stumble upon SPA that can't even get navigation right.

But the main reason is still this:

I compared the serverless website (considered a state of the art SPA) with the hackernews website (considered a student level website) on an edge connection in the German country side:

Hacker news:

- first load: 6 seconds

- next loads: 3.5 seconds

Serverless:

- first load: 26 seconds

- next loads: 7.5 seconds

For a webpage displaying static text.

I agree with you as well, SPA are generally slower and the navigation always has issues as the application grows. I guess reimplementing the browser navigation is a bit complex.

I think a good SPA is a superior experience but a bad SPA is worse than a traditional page load approach.

> 26 seconds

It takes like 4s for me.

Though I think you're kidding yourself if you think HN is typical.

I can't see any reason why there should be anything but a very small difference on way or the other.

> It takes like 4s for me.

You are not on an edge connection then.

> Though I think you're kidding yourself if you think HN is typical.

No, but serverless and NH have the same purpose of mostly displaying text.

What's an "edge connection"?

http://edgeconnection.net/ ?

but pageload based frameworks abstract almost all of that mess away from the developer, where was an SPA has less of that mess, but a bunch of different messes.

I don't advocate for pageload-based frame works (asp.net webforms, cf, a bunch of roll your own phps, etc), and I believe a lot of the vendors of them have been kind of moving away from them toward a more bare-metal HTTP approach, but that doesn't mean they don't have a place.

In RAD and click and drag IDEs that large corporations prefer, you can hand a single Junior level developer a requirements document, and expect them to be able to build a back-office type application.

You've made a key point here that I continue to struggle with handling consistently: managing the address/history for an SPA. Is there any prescriptive guidance for doing so that is consistent within a given framework (e.g. Vue, React)?

I dunno about prescriptive, but in React the use of `react-router` and `history.push` certainly seem to tick the boxes in my use cases.

It might as well have just said "get off my lawn" and nothing else.

It starts with a list of things that everybody obviously wants, goes on to give very specific examples with absolutely no backing or evidence, and finishes with some hand-waving "you get the idea".

Also, "nor will we defend our lack of knowledge of their hyped and volatile technologies" really comes off as complacent ignorance.

The best way to try and fight something is to first learn about it. You might even learn that the thing you're fighting has some useful lessons in it.

Really well done SPA by small players are very rare though. So no, I wouldn't say it's proven.

Anybody can code a HN clone. An SPA HN clone that is not a total disgrace though ?

I think it would be quite easy to do using a framework like next.js[1]. For more complex applications it can be challenging to get an SPA to work right, but for things that behave more like websites than web applications (primarily just as linked documents) there are frameworks that make it trivial.

[1] https://nextjs.org/

If you make a web site, don't make a SPA. The a in spa stands for application.

Despite their proliferation, SPAs are still nowhere near as popular as traditional page-reload websites. And they shouldn't be - much like micro services and NoSQL, they require additional justification. If my friend tells me he's using Postgres at work, I won't give it a 2nd thought. If he says he's using CouchDB, I'll say "Interesting. What made you choose that?"

The author has probably been burned by people who use shiny/new tech just because it's shiny/new. And I guess he thought we needed a manifesto for this situation. But I agree, the "get off my lawn" tone makes it not very effective IMO.

I think a huge part of the shiny tech proliferation comes from the pseudo-agile movement. Usually pseudo agile means one thing: no spec.

You get a team tell them "let's do this widget" with no detail, no edge case scenario, no perf requirement. So they choose last awesome tech which solution a problem they got last time and will look good on a resume. And only after a month or two of making things do the real hurdle of this tech start appearing. All the things you never see mentioned in those "let's get started" tutorials or shiny-techs online conference.

With some time spent thinking about the problem space and what happen when things go bad your team could have sensed that nothing is all sugar and rainbows. Take micro services: at first it looks elegant. But when you start thinking about how to manage transactions for some actions across multiple services or how to handle some of your server dying then coming back to life you suddenly have the urge to stop and check if you really need this kind of architecture at first.

Unless you're explicitly looking to experiment with a specific technology or framework, I think its a good practice to start your implementation reasoning from a boring perspective. What this means for you personally will vary based on your skillset. However, if you can pull something off in an "engineering-easy" way, you can be wildly productive.

With that said, you have to be smart and know when boring is not enough. 3-tier apps are great until complexity pushes them into gnarly monolithic messes that resist change. And with some sensible UX thinking adopting SPAs can push your user experience forward. NoSQL databases might not be the best choice as your primary datastore but might be a better alternative than materialized views (Graph databases are often utilized by some organizations as part of their secret sauce)

> I've worked with plenty of "page reloads" frameworks that were at least as complex as their SPA counterparts. I get that you don't like Javascript, but seriously, SPA is proven and popular at this point too.

It's certainly popular. I wonder if sites like github would be simpler for users, developers, and devops if they just embraced SPA - judging by your comment, maybe?

I've never worked for a company that said "we are going to use technology that takes twice as long to implement new features."

Even when I worked in a boring industry like advertising and banking they expected things to be done by next sprint and were very accepting of the instability tradeoff.

I'm not saying that they're thesis is wrong: boring but stable software is a Very Good Thing, but it's not just us devs wanting to use the latest and greatest that's driving such quick tech adoptions.

I think the point is _some_ devs want the latest shiny thing in prod. So no one says "we are going to take twice as long" but "we need to use X" when maybe we don't.

I also use micro services on a daily basis, which this manifesto seems to dislike very much so I'm more of the opinion that pragmatism should be priority #1

Need micro services? good, use it

Need an ORM? why not (though use with care)

Need a relational databse ? go for it

Need noSQL? sure

Just make sure you have a good reason to pick whatever you work with, and usually the simpler the better.

They all have pros and cons and I feel this manifesto might be more of a knee jerk reaction rather than trying to solve anything

Yeah the anti-microservice sentiment is a bit bizarre. It almost reads like the author wants to stick with Ruby-On-Rails circa 2005 as the be-all, end-all of application architecture.

Don't get me wrong, there's such a thing as innovation for its own sake which does not add value, but there is nothing wrong with a single-page application driven by microservices. That architecture is pretty well proven and "boring" at this stage.

It's not bizarre, it's experience outside of big shops.

First, you probably don't need it. There is a scale at which you benefits from microservices more than they cost. Most companies don't have that scale.

Secondly, unless you have three 10x programmers in your team, the microservice architecture is going to add a lot of complexity that will be a burden to manage.

So as usual, it's what you get VS what it costs.

Micro services are not free.

I would suggest that there is a nontrivial difference between a service-oriented architecture and microservices, and there can often be a lot wrong with the latter when misapplied. In smaller teams, thinking in terms of a service-oriented architecture (I prefer "product-oriented architecture", where something like a shared auth service is a product making semi-formal or formal contractual guarantees to its customers, internal or otherwise, at a business rather than a code level) tends to break up into larger pieces of functionality. You are still paying a cost for doing so, but I have found most clients to be more receptive and better able to manage, say, three of them, rather than a dozen or more.

Most teams don't have the problem that microservices actually exist to solve: a fractured org chart. Because that's when you want and need microservices--when your org chart's reporting chains are separated to the point where you need to separate functionality for human and political reasons, so as to avoid having one set of interests stomp on another. There's a geometric cost to any services; generally speaking one should be sure that the carried organizational and technical load of adding another (in the microservice-swarm pattern this load is smaller on margin but heavier in frequency, and it adds up) has positive ROI.

It's basically boiling down all software and computer science to 'simple' versus 'complicated' but the problem is, what's simple and what's complicated is always relative to your frame of reference.

If you are used to thinking in one paradigm in a very rigid way, of course the other is going to be hard to comprehend, hard to use, challenging to implement, and difficult to maintain. That doesn't make one solution objectively better or worse. Pick the right tool for the job. Sometimes the right tool starts with the way the mind is thinking about the problem.

All of this can drive you insane to get 'perfect' especially when technology moves fast, and the world changes. So at the end of the day, 'good enough' is usually 'good enough'.

I feel like a lot of the advice out there about software and software philosophy are just venting steam sometimes, because, people who work with software and hardware often have to not only deal with a machine telling them the way they do things are wrong (like an error message, or just trying to figure out how to make the thing do what it's supposed to do) but also plenty of people around them, saying "this is the right way to do things". Yes, it is the right way to do things, sometimes.

There's some good principles in there, but I do hope people inject a little common sense / nuance instead of interpreting them in the way that eg. the agile principles are often interpreted (carved in stone, handed down by the almighty, etc.)

If there's any principle I'd take issue with, it's "built exclusively with popular and proven tools". Perhaps a good rule of thumb, but sometimes your particular needs step off the well trodden path, and it'd be a shame to see someone clinging to this dogmatically instead of considering alternatives that might get the job done easier / quicker / ...

They should have also added the following to their examples:

* vacuum tubes over transistors

* goto over functions

* inheritance over composition

* your favorite last decade best practice here

This manifesto just moves the argument to what industry best practices are (hint: it's not page reloads for every single interaction for most things).

I think more than "latest and greatest", devs should be looking for simplicity. I really like Dan Abramov's approach to Javascript in React/Redux and he does a great job of proving simplicity in some of his Redux tutorial videos by recreating Redux from scratch via test assertions.

As a trainer getting to train people in many tech, I experience the opposite feedback in the classroom. As a dev, I always feel like picking redux as simple is like picking a shovel as a simple solution to dig a tunnel.

Tell me that mobx is simple. Or vue. Or jQuery.

Redux is not simple. It's basic.

When I think of a software "manifesto", I think http://utf8everywhere.org and https://12factor.net. This is kind of fluffy by comparison.

I feel that their examples are poor - Microservices, SPAs and NoSQL DBs are well proven at this point. That doesn't mean they are always used correctly, though. This has nothing to do with either embracing or eschewing the latest frameworks. It is much more about understanding the available tools, their strengths and weaknesses, and applying them to the correct problems.

In short, embracing a framework based on hype is not a great move. But neither is rejecting a framework just because it has hype.

>The things on the left that are simple and proven, while the things on the right are hyped and volatile.

>3-tier applications vs. micro services

As yes, the volatile and unknown territory of the architecture formerly known as "Service Oriented Architecture" that has been in use since at least the early 2000's.

I get what this guy is trying to say, but examples like this don't help.

Ultimately, I don't subscribe to his manifesto any more than I subscribe to manifestos about SQL being dead or monoliths being poison in all cases.

These things are all tools in the toolbox. You'll use some of them more than others during your career. You might use a given tool a lot because you like it, or you might use it a lot because it's a really useful tool even if you hate it. Both are fine. In addition, you'll find that sometimes you really /do/ need a triwing screwdriver, so it's nice to have that in your toolbox as well.

Don't be that guy who throws out either SQL /or/ NoSQL just because he likes the other thing or thinks it's more widely applicable. Both technologies suit some use cases the other doesn't. Use the tool that's right for the job, don't get culty about trying to wrangle an ill-fitting tool to a job it was never designed for just because you've tied your ego to it.

This is a satirical piece, and I don't know how that was missed. Of course, if I'm wrong, and the author wrote this to be taken literally, then this is a poor manifesto to follow. It seems clear the author was trying to point out how backwards it is to argue against using popular, supported, and progressive technologies. I'm going to inquire if it was in fact satire, but it seems like it to me.

As a developer of 36+ years, I have 'some' authority to say this. You made some good points but stop! I think the other commenters here have patiently covered the salient points. You work in an industry that is evolving.

This is awful advice. The tooling for things the author describes as harmful are as mature as the "stable technology"...

It's easy to forget the time and effort to accumulate the knowledge for fighting the limitations to a technology you've familiarized yourself with.

- A SOA approach requires less stack knowledge overhead and $$$ for actual deployment and use than monolithic applications.

NoSQL vs SQL? Not everything fits on a spreadsheet. Just because you've gotten good at wiggling things into one doesn't mean that you're right.

> Posted 4 times in twelve days.

Who is upvoting this?

One of the reasons I prefer SQL is it seems to be better are representing non relational data than NoSQL is at representing relational data. ( Not to mention the decade head start on tooling)

Why make it either-or?

I prefer NoSQL when there are scaling needs, because it _can_ scale horizontally. Sometimes it's just easier to use, too, and there are times when the feature set maps _much_ better onto the problem at hand.

Not all of your data access needs to scale horizontally, though, and if you have relational data you should use a relational database unless your scaling needs are extreme.

I don't disagree except for the tiny edgecase where graphs are useful. The SQL/ NoSQL tradeoffs are well documented, saying NoSQL is hyped and volatile is silly.

Can't we just agree that a middle way is the way to go? Just look at the strawman battle this article as well as these comments here. It's basically:

- "So I should only want to use vacuum tubes and Windows ME for my cutting-edge start-up? You call yourself a dev?!?!"

- "So I should update my legacy backend application every month with every twitter trend? You call yourself a dev?!?!"

I mean, the answer is painfully obvious: Start at the middleway and then move right or left depending on your scope, customers, budget and culture...

The middleway is not the problem. As you mention about the strawmannery; the problem is that often the "tried and tested" people are resistant to trying something else.

On the other extreme, the "React, SPA, SSR" people often discredit the page reload thing without thinking whether it works in the scenario.

I'm all for learning both ways, but don't like it when someone suggests something without objectively motivating why.

I'm about to head home for the day. We were just discussing this a few hours ago.

We're dealing with an interesting case where being the "shiny things that solve problems I don't want to deal with" person, we are struggling to get developers who can help our team.

We're doing some accounting software, and instead of the "boring software", we chose to:

1. Use Kotlin over Java

2. Use gRPC over REST

3. Use microservices over a monolith, or 3-tier whatnot

4. Use "containers" over "Java application containers".

Firstly; for the kind of gig we're doing, we've only been able to find developers experienced with Java EE, some who've mainly used Java 6 because some of the large shops are "that behind".

We got a software architect so that I could focus on other things, and he started off by wanting to tear everything apart, and move us to "boring software".

He's had some success, but slowed us down a lot in the process. For example, he was uncomfortable with Docker or containers because in his mind, many clients still deploy GlassFish and JBoss/WildFly containers. So we were forced to get gRPC working on those application servers. He was unhappy with the idea of exposing ports (even internally) other than the standard 8080.

Then he didn't like that we were handling transactions manually, which was fine; so we moved to JPA. We implemented JPA with local resource transactions, and it was a mess trying to merge our Frankenstein with JTA transactions on the container. After we wasted a week, he conceded that we can keep local resource transactions.

He said that no client should consume RPC methods (he hadn't researched what gRPC 'solves'). So his suggestion was that we add a REST proxy on top of the gRPC endpoint that the front-end connects to. I tried explaining that the front-end already uses gRPC, but he insisted that the front-end would also have to proxy to JSON.

So, I explained that:

1. We have devs at varying levels, some beginner (because resource constraints), so Kotlin is easier than Java, to equalise the field. He was uncomfortable with mixing Kotlin with Java.

2. gRPC ensures that we have sane contracts between our services, making it easier to separate our offering into little modules. Imagine a client using SAP wanting to integrate our solution into SAP. Instead of modifying the guts, we can create a small service that connects to the API to do that. I also personally wanted type-safety, and to not deal with errors like "the date format is incorrect" (which I dealt with during the prototyping days last year).

3. Microservices; we were able to abstract our database logic away from the business rules. Yes, JPA and Hibernate handle connecting to different database types, but we wanted further separation should we ever need to build with a different datastore (unlikely, but I built the prototype in 'Record Time (TM)' with MongoDB).

4. I had a Docker Compose script for the entire thing running in under an hour (incl. Docker build etc.). I had to step in on the ops side after a month of our JBoss thing still not working.

______

So, new and shiny tech often solves certain problems that we think don't exist, but until you use the tech, you won't realise that what your "boring software" was doing was less effecient.

Ask any developer who's written Java and earnestly learnt Kotlin. Ask anyone who used to deploy the "boring" way and now used containers. Ask any integration engineer who used to parse JSON and now uses Thrift or Proto.

Sounds like your architect was a bad fit.

Uncomfortable with Docker? Today? Or microservices? Or mixing Kotlin with Java?

I haven't used gRPC myself, but it looks like a strong standard. I have used Protocol Buffers in the past, though, and I certainly wouldn't be afraid of it just because I hadn't used it.

I've seen this kind of ultra-conservative outlook with Java developers fresh from enterprise jobs. Worked with one developer briefly who insisted that every new API would take at least two weeks of work. Even if the API was completely trivial CRUD. When I mentioned that I was using a framework that could stand up a new CRUD API in minutes, complete with authentication, validation, and user-based access protection, the developer called me a liar.

Which was funny because I'd just done _exactly that_ for another client, standing up the entire stack _and_ creating ~40 CRUD REST APIs (with parallel Socket.io APIs for real time updates) in about 8 hours. Adding or changing a model for one of the databases from that point forward just required a few lines of model specification code; additional custom code per-API was entirely optional. Of course I wasn't using Java Spring, so that may have been an unfair advantage, but there's a reason I don't use Java Spring...

Interesting that you talk about Java Spring, because I was partly lambasted for not using a Java framework.

I thought Spring is good. What's wrong with it?

It's slow (execution speed [1] -- it's slower than Node.js by a lot!), and every developer that I've spoken to has given very, very long estimates (from my POV) for accomplishing even trivial API work, so it seems to be prone to low development velocity. It's possible that every single Java developer I've worked with is nigh incompetent, but they had jobs at places like Oracle, Amazon, and high-end consulting companies, so I'm not sure where the strong Spring developers are hiding.

I don't know the internal architecture, but given the poor benchmark results, I'd hazard a guess that Spring also functions as a thread-per-connection server, which means resource use would be very high for real-time applications (compared to Node.js or an event-based Java framework). And most applications today require at least a real-time component, so if you need 10x-50x as many application servers because you need an OS thread per concurrent connection, that's a huge additional cost.

[1] https://www.techempower.com/benchmarks/ -- Java and C++ tend to be the fastest in the benchmarks, but Spring is so slow that it hits between 2-16% of the top platform speeds, depending on benchmark.

Reply on news.ycombinator.com