
The “Boring Software” manifesto - amanzi
https://tqdev.com/2018-the-boring-software-manifesto
======
jsight
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.

~~~
CamTin
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.

~~~
spdustin
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)?

~~~
eropple
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.

------
bamboo_7
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.

~~~
alex_duf
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

~~~
skohan
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.

~~~
sametmax
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.

------
jsty
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 / ...

------
jupp0r
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).

------
swoongoonz
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.

~~~
sametmax
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.

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

------
codingdave
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.

------
Sir_Substance
>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.

------
mcd160230
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.

------
hitchhiker999
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.

------
tfolbrecht
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?

~~~
JamesBarney
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)

~~~
SomeCallMeTim
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.

------
blackbrokkoli
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...

~~~
nevi-me
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_.

------
nevi-me
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.

~~~
SomeCallMeTim
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...

~~~
nevi-me
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?

~~~
SomeCallMeTim
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/](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.

