Ask HN: Are we overcomplicating software development? - ian0
I have recently been involved in the overhaul of an established business with poor output into a functioning early/mid stage startup (long story). We are back on track but, honestly, my lessons learned fly in the face of a lot of currently accepted wisdom:
1) Choose languages that developers are familiar with, not the best tool for the job
2) Avoid microservices where possible, the operational cost considering devops is just immense
3) Advanced reliability / redundancy even in critical systems ironically seems to causes more downtime than it prevents due to the introduction of complexity to dev & devops.
4) Continuous integration seems to be a plaster on the problem of complex devops introduced by microservices.
5) Agile "methodology" when used as anything but a tool to solve specific, discrete, communications issues is really problematic
I think overall we seem to be over-complicating software development. We look to architecture and process for flexibility when in reality its acting as a crutch for lack of communication and proper analysis of how we should be architecting the actual software.
Is it just me?
======
SatvikBeri
Many of these practices are popularized by Google/Facebook/Amazon but don't
make sense for a company with 100 or even 1,000 people. I try to focus on
whether a practice will solve a concrete problem we're facing.

Switching from Hadoop to Spark was clearly a good idea for our team, even
though it required learning a new stack, but there isn't a strong reason to
switch to Flink or start using Haskell.

Agile makes sense when your main risk is fine-grained details of user
requirements, but not when you have other substantial risks, such as making
sure a statistical algorithm is accurate enough.

Microservices probably reduces the asymptotic cost of scaling but add a huge
constant factor.

Relational databases are the right choice 95% of the time, non-relational
stores require a really specific use case.

TDD is good for fast feedback in some domains, but for others, manually
investigating the output or putting your logic into types is better. E.g. a
lot of my time comes from scaling jobs that work on 10gb of data but crash on
1tb, TDD is not that helpful here.

Continuous integration mostly makes sense when you're making a lot of small
changes and can reliably expect a test suite to catch issues.

In short, ask the question "when is practice X useful?" instead of "is
practice X a good idea?"

~~~
kosinus
One thing that bothers me is the 'relational databases are good enough'
statement, that is repeated in other contexts as well.

But especially here, where we're talking about reducing complexity, it feels
off to me. PostgreSQL and MySQL seem to me like incredibly complex packages.
SQL, the language, is not easy to master either; most programmers I meet know
mostly basics. On top of that, there's a long ongoing history of security
malpractice.

When talking about reducing complexity, CouchDB and Redis are far easier
alternatives, in my humble opinion, though they go slightly against 'use the
tools developers know'.

~~~
pg314
The implementation of PostgreSQL is complex, no doubt about that. But if you
need strong data consistency and durability guarantees, it provides a rock-
solid foundation.

SQL might take some getting used, but it is also not rocket science. It
shouldn't take more than a week's study to master the basics. There is of
course a lot of awful SQL code out there, exactly because most programmers
don't even know the basics. You can do incredibly powerful things in it that
would take 10x the code in an OO/procedural language. In my opinion dumping an
ORM on top is also not the best way to leverage the strengths of an RDBM.

It is slightly ironic that you bring up security malpractice in the context of
PostgreSQL, when in the next sentence you advocate Redis as a far easier
alternative. As was recently in the news the Redis defaults were for a long
time insecure (google for Fairware ransomware).

~~~
TeMPOraL
> _In my opinion dumping an ORM on top is also not the best way to leverage
> the strengths of an RDBM._

I agree. Unfortunately, the way I see people usually using them is pretty bad
- you should not let ORM-generated stuff dictate your business model. Database
is a database. A storage layer. Business objects will _not_ map 1:1 to ORM
objects. Approaches like "let's inherit from ORM class and add business-
related methods", in my experience, lead to total disaster. One has to respect
the boundary between storage layer and business model layer.

~~~
icebraining
I'm aware of the different approaches (mostly from reading Fowler's PoEAA),
but currently we use an Active Record-style ORM with a few extra features
(like Class Table Inheritance) and we haven't found any major issues with this
approach. What was the worst case scenario you experienced with the 1:1
approach?

~~~
TeMPOraL
Over the past 5 years I've been in two projects using 1:1 ORM Active Record ==
business model base approach. One completely failed in part because of this,
second is barely manageable, but I managed to save it by moving business code
mostly to the outside of Active Record classes.

The problem I encountered in those projects is the mismatch between storage
mental model and business mental model, which lead to explosion of crappy code
(AKA technical debt). In particular:

1\. the classes I need for business model _may_ have initially mapped well to
database tables, but over time they stop; business logic and model changes
much faster than you'd like your DB schema to

2\. since many things in AR can fire SQL queries, you have to keep in mind the
workings of your database when doing almost every operation on your model;
it's an abstraction leak

3\. code shooting off SQL queries is randomly called from all over your
codebase; it's harder to keep track of it and, if needed, optimize those
queries

I like AR as a convenient API to get data from/to database, but given the
point 1., I eventually learned to isolate AR layer as something _below_
business model layer, so that the pattern is that business model is explicitly
serialized and deserialized from database, instead of the database being
coupled with the logic of your program.

Now I vaguely recall complaining about this before on HN and getting my ass
handed back to me by someone who pointed out that these are all ORM n00b
mistakes. I wish I could find that comment (pretty sure I noted the link down
somewhere). Yeah, I admit - in those two projects I mentioned, we were all ORM
noobs. So we've learned those lessons the hard way.

------
PaulHoule
Continuous integration is a good thing. Back in the bad old days you'd have
three people working on parts of the system for 6 months and plan to snap them
together in 2 weeks and it would take more like another 6 months.

Agile methods are also useful. If you can't plan 2 weeks of work you can
probably not plan 6 months.

When agile methods harden into branded processes and where there is no
consensus on the ground rules by the team it gets painful. The underlying
problem is often a lack of trust and respect. In an agile situation people
will stick to rigid rules (never extend the sprint, we do all our planning in
4 hours, etc.) because they feel they'll lose what little control they have
otherwise. In a non-agile situation people can often avoid each other for
months and have the situation go south suddenly. In agile you wind up with
lots of painful meetings instead.

Also I think it is rare for one language to really be "best for a job". If you
want to write the back end of a run of the mill webapp, you can do a great job
of that in any mainstream language you are comfortable in.

~~~
reacharavindh
> Agile methods are also useful. If you can't plan 2 weeks of work you can
> probably not plan 6 months.

Hmmm. I was just thinking the opposite yesterday. I'm a performance engineer
working closely with two teams. One doing Agile and the other basing on wikis
and Adhoc in-person whiteboard discussions. I find the non agile team more
productive, efficient and dare I say happy. The Agile based team makes me sit
in on their daily scrum meetings. Although every one uses it to sync up on
their dependancies, it just drags for an hour almost every day. I can visibly
tell the devs walking out of the room spend more time worrying about
"velocity" and "organisation of work" than the money making work that needs to
be done. It almost feels like the agile process gives them "one more job" of
picking the doable things from the list of stuff that needs to be done so they
look better than their peers with better velocity.

Simply put, I was thinking if Agile is just not a good method when you can
strive for good leadership and a healthy collaboration among individuals of
the team?

~~~
iainmerrick
_One doing Agile and the other basing on wikis and Adhoc in-person whiteboard
discussions._

The ad-hoc approach also sounds quite agile (at least with a small 'a'). It's
certainly closer to Agile than to Waterfall, assuming they didn't do a big
design up front before writing any code.

I think the ad-hoc agile approach can work very well with a good team. But
Scrum fans always seem to warn against cherry-picking just the bits of Scrum
you like and not using the whole process.

~~~
btilly
_But Scrum fans always seem to warn against cherry-picking just the bits of
Scrum you like and not using the whole process._

But of course. If you just cherry-pick and experiment, then you won't have any
reason to pay an expensive expert to tell you how to do it right!

------
BjoernKW
No, it's not just you and yes, we often do overcomplicate software
development.

It's been that way long before agile methodology or microservices though.
Complexity-for-the-sake-of-complexity EverthingHasToBeAnAbstractClass
frameworks have been plaguing the software development business since at least
the 1990s and I'm sure there are similar stories from the 80s and 70s.

It's hard to find a one-size-fits-all easy method for not falling into that
over-engineering / over-management trap. I try to focus on simple principles
to identify needless complexity:

\- There is no silver bullet (see "microservices"): If the same design pattern
is used to solve each and every problem there probably is something amiss.

\- Less code is better.

\- Favour disposable code over reusable code: Avoid the trap of premature
optimisation, both in terms of performance and in terms of software
architecture. Also known as "You aren't gonna need it".

\- Code means communication: By writing code you’re entering a conversation
with other developers, including your future self. If code isn't easily
comprehensible again there's likely something wrong.

~~~
cookiecaper
I think the tendency to over-engineer is a symptom of retrofitting an
assembly-line 9-5 shift onto the creative process of writing code.

You sit a guy there 5 days a week for many years. He has to look busy, he has
to do something with all of that time. He's not going to get paid if he writes
the code in the most simple, concise, and straightforward way possible and
then goes home until they're ready to make a new feature two weeks later. He
has to sit around and make up something for himself to do.

Contrast with side projects. I have many simple weekend projects that continue
to work well and provide their promised utility years later. Because you just
write what you need and stop, you don't get sucked into the disastrous
complexity spiral that every company-internal software project ends up as.

The other factor here is that people need some signal to say "I'm good at my
job" (because no one can actually tell). That signal has to go to colleagues,
superiors, and peers outside the workplace. People therefore invent artificial
complexity or take intentionally convoluted approaches so they can sound
fancy. In the most extreme cases, this is a conscious decision designed to
block out "competitors" (colleagues). In many cases, it's a subconscious way
to ego-stroke (and to mix in a little bit of variety per point one above).

This is especially true when a household brand like Google or Facebook pushes
out some new esoteric thing; everyone wants to see themselves as a Google-or-
Facebook-in-waiting and it makes it easy to pitch these things to the bosses,
when the fact is that the kinds of things that work at large public companies
like Google are probably not going to work in small companies.

~~~
nathanaldensr
Thank you for shining a light on the psychological side of this discussion. I
like to highlight psychology when I have these discussions with peers because
too often technical folks view the world through technology lenses instead of
human ones.

------
corysama
One of my fav tech talks ever (and I watch a lot of tech talks) is Alan Kay's
"Is it really 'complex'? Or, did we just make it 'complicated'?" It addresses
your question directly, but at a very, very high level.

[https://m.youtube.com/watch?v=ubaX1Smg6pY](https://m.youtube.com/watch?v=ubaX1Smg6pY)

Note that the laptop he is presenting on is not running Linux/Windows/OSX and
that the presentation software he is using is not OoO/PowerPoint/Keynote.
Instead, it is a custom productivity suite called "Frank" developed entirely
by his team, running on a custom OS, all compiled using custom languages and
compilers. And, the total lines of code for everything, including the OS and
compilers, is under 100k LOC.

~~~
GnarfGnarf
That is absurd. You can't write an OS in 100KLOC.

~~~
srpeck
Check out stats on the kOS/kparc project:
[https://news.ycombinator.com/item?id=9316091](https://news.ycombinator.com/item?id=9316091)

There is also a more recent example of Arthur Whitney writing a C compiler in
<250 lines of C. Remarkable how productive a programmer can be when he chooses
not to overcomplicate.

~~~
nickpsecurity
Everything I saw in the link looks like K, not C. Do you have a link to the C
compiler done _in C language?_

------
majewsky
1) False dichotomy. Developer familiarity is one of the most important metrics
for choosing "the best tool for the job".

2) Conway's Law applies in reverse here: If your organization consists of a
lot of rather disjoint teams, then microservices can be quite beneficial
because each team can deploy independently. If you're one cohesive team, there
is not much benefit, only cost.

3) Depends. If you have a well-designed distributed system, it can be
amazingly resilient and reliable without introducing much administrative
overhead. (From my experience, OpenStack Swift is such a system. Parts may
fail, but the system never fails.) There are two main problems with
distributed systems: a) Designing and implementing them correctly is really
hard. b) Many people use distributed systems when a single VM would do just
fine, and get all the pain without cashing out on the benefits. See also
[http://idlewords.com/talks/website_obesity.htm#heavyclouds](http://idlewords.com/talks/website_obesity.htm#heavyclouds)

4) Continuous integration was not meant to help with complexity. Its purpose
is to reduce turn-around time for bugfixes and new features. If your release
process is long and complicated, the increased number of releases will indeed
be painful for you. Our team sees value in "bringing the pain forward" in this
way. Your team obviously puts emphasis on different issues, and that's okay.

~~~
UK-AL
I find microservices can help in just keep everything small and focused. I
know you can do this with a monolith. But having a process boundary really
enforces it.

~~~
crdoconnor
I find that the boundary creates operational headaches. A function call won't
time out, deliver a 502 error, have authentication/authorization issues,
require load balancing, etc. etc.

A REST API will.

Plus, once you've debugged a problem that involves crossing 5 microservice
boundaries you'll start to wonder if it was all worth it.

Monolith is also a wrong (and somewhat derogatory) word to describe a non-
microservice architecture. There's nothing monolithic about loosely coupled
code running on the same machine.

I really think that microservices are a hack to deal with conway's law in
large corporations. Operationally it's inefficient but it fixes a nexus of
technical and political problems when the correct boundary is picked.

~~~
UK-AL
Except most applications are monolith. Monolith code can still be loosely
coupled. However it is harder.

~~~
crdoconnor
No, not at all.

The only difference I noticed with respect to rube goldberg (what you call
"microservices") systems and coupling is that tight coupling between
components of rube goldberg systems was much more painful: particularly
debugging across multiple service boundaries.

------
mhotchen
Many of the programmers I have worked with actually love complexity, despite
trying to convince others (and most likely themselves) that they hate it.

Advice tends to be cherrypicked to suit an agenda they already have (with your
example on microservices, the vast amount of resources saying they're very
difficult, should be driven by a monolith first approach, and solve a specific
set of problems is largely brushed under the rug).

I think because our industry moves so fast there's a fear of becoming
irrelevant. Ironically companies are so scared of not being able to employ
developers that they're also onboard with complicating their platform in the
name of hiring and retention. I think this is down to the sad truth that most
developer roles offer very little challenge outside of learning a new stack.

~~~
jamesmccann
> I think this is down to the sad truth that most developer roles offer very
> little challenge outside of learning a new stack.

This is a gem observation from this thread. In my own tech sphere the first
thing developers are talking about with each other is the new x,y,z lib or
framework they're using to accomplish something relatively banal. There's
still a lot of work out there that really boils down to basic CRUD and
reporting at the end of the day, and developers naturally begin to invent
complexities on top of that CRUD to make the work interesting and challenging.
I'm absolutely guilty of this first hand.

I've found personally it also doesn't help that past work on projects e.g.
large Rails apps that were never architected well turn out to be such
nightmares to work on. The memory of the end state of these projects lingers
with developers as they move onto the next piece of work, and they're inclined
to say "no that doesn't work" and pick up shiny new-tech to do the old job
instead.

As a side analogy: most small business construction jobs, e.g. building a
timber frame house, don't involve the builders arriving on site and are
stumped by the challenge of how to put up the framing for the bedroom walls -
there's also very little challenge in these projects, yet the reward is in the
completion.

~~~
brwr
> There's still a lot of work out there that really boils down to basic CRUD
> and reporting at the end of the day, and developers naturally begin to
> invent complexities on top of that CRUD to make the work interesting and
> challenging.

I'd go so far as to say that _most_ work today (at least in startups) is
building CRUD apps. The technology has changed, but the work hasn't. Inside of
building CRUD apps in Rails, we now build them in React.

------
DanielBMarkham
You've thrown together a bunch of buzzwords and asked if we are over
complicating things.

Buzzwords can mean freaking anything. I've seen great Agile teams that don't
look anything like textbook Agile teams. Microservices can be a total
clusterfuck unless you know what the hell you're doing -- and manage
complexity. (Sound familiar?) CI/CD/DevOps can be anything from a lifesaver to
the end of all life in the known universe.

So yes, we are over complicating software development, but the way we do it
isn't through slapping around a few marketing terms. The way we do it is not
understanding what our jobs are. Instead, we pick up some term that somebody,
somewhere used and run with it.

Then we confuse effort with value. Hey, if DevOps is good, the more we do
DevOps, the better we'll be, right? Well -- no. If Agile is good, the more
Agile stuff we do the better we'll be, right? Hell no. We love to deep dive in
the technical details. If there aren't any technical details, we'll add some!

Software development is too complicated because individual developers veer off
the rails and make it too complicated. That's it. That's all there is to it.
Throw a complex library at a good dev and they'll ask if we need the entire
thing to only use 2 methods. Throw a complex library at a mediocre Dev and
they'll spend the next three weeks writing 15 KLOC creating the ultimate
system for X, _which we don 't need right now and may never need_.

It has nothing to do with the buzzwords, the tech, or software development in
general. It's us.

------
sebringj
It never seems complicated when I am doing my own side work for some reason.
There are no design meetings, no hours tracking, no arguments on best
practices, no scrum, no testing frameworks, dev ops, etc. I do use git and
minimally create bash scripts to simplify repetitive tasks for deployment but
its just a huge contrast to working in teams where something simple takes
about 50 times longer.

I think keeping things as simple as possible and always going for that goal
will increase velocity overall. Everything should be subject to scrutiny for
promoting productivity and open to modification or removal. I know there is a
balance where you have to increase complexity in a team environment but
keeping friction as low as possible in terms of process and intellectual
weight couldn't hurt.

The most productive place I've seen so far is a huge athletic brand I worked
for where they kept teams at max 5 people in mini projects. This forced the
idea of low overhead and kept the scale of management needed small. The worst
place I worked for in terms of unnecessary complexity is a well known host,
although it is the best place to work in terms of people, hired offshore that
has a one-size fits all mentality and layered in as much shit as possible to
slow down development to a mud crawl. I don't buy into process over
productivity.

~~~
ashark
One of the things that helps when you're developing your own projects is that
you can single-handedly decide to ruthlessly cull parts of the project that
take lots of time but provide little value, and you (probably) have decent
insight into what those are. You're also probably not at a scale where doing
certain really crappy, slow parts of the job can pay off, so you can skip
those.

Default form elements with some basic, nice styling to fit your theme? Form
done in one hour. Special snowflake version of the same thing from the design
team, which has no idea what the platform can and cannot easily be made to do,
but the client is absolutely in love with? Two _days_ , a third party
dependency or two, some extra environment-specific bugs to track down later,
and generally increased fragility (so more time lost in the future). This has
slowed you down now and increased the resources required for the project
indefinitely. But the client looooooves it.

Support Android pre-5.0, at the cost of 20% more development time, a pile of
extra bug reports, an uglier, harder-to-maintain codebase, and a much much
longer testing cycle, for a side project? _Hell_ no. Client says that will
cost them $4 million/yr not to support those? Ugh. FINE.

And so on, and so on.

------
mschaef
Continuous Integration is (with a reasonable test suite) one of few elements
of software development that I would consider almost essential for any long
running project. It's just too useful to have continual feedback on the
quality of the system under construction. (And this is before bringing in
micro-services or any other complicating architectural pattern.)

Where I might agree with you more are on points 3 and 4: 'Advanced
reliability' and 'Microservices'. While I have no doubt that these are useful
to solve specific problems, I think as a profession we tend to over-estimate
the need for these things and under-estimate the costs for having them. To me
this implies that there needs to be a very clear empirical case that they
support a requirement that actually exists. I'd also make the argument that
the drive for microservices within an organization has to come from a person
or team that has the wherewithal to commit resources over the long-term to
actually make it happen and keep it maintained. (ie: probably not an
individual development team.)

------
rolodato
I think the "learn to code" movement as well as overly-technical interviews
for developers are partly to blame for this. It's well-known that developers
are tested on how to do something that's considered technically difficult,
such as abstract CS problems or a complicated architecture, but they are
rarely asked why certain tools, practices or architectures should or should
not be used. Comparative analyses to make objective recommendations between
different solution alternatives are also rare in my interviewing experience,
but they are one of the most valuable skill a competent software engineer
should have.

I don't agree on point 4 though - CI can be something as basic as running a
monolith's tests on each commit, which makes sure that builds are reproducible
(no more "works on my machine").

------
bluejekyll
No. You are correct. Honestly I think you can solve a lot of that by following
on from one of Deijkstra's core priniciples: Seperation of Concerns.

When you practice good seperationof concerns, specific choice in different
areas can be more easily fixed later. It requires having decent APIs and being
thoughtful on the interaction of different components, but it helps immensely
in the long run.

Microservices are one way to practice seperation of concerns, but it can also
be practiced in monolithic software as well, by having strong modular systems
(different languages are stronger at this than others).

------
marcosdumay
Well, yes, we are overcomplicating it. Except on the parts we are
undercomplicating... And I still couldn't find anybody that can reliably tell
those apart, but the first set is indeed much larger.

1 - Do not pick a new language for an urgent project. Do look at them when you
have some leeway.

2 - Yep.

3 - There's something wrong with your ops. That happens often, and it is a
bug, fix it.

4 - If CI is making your ops more complex, ditch it. If less complex, keep it.
In doubt, choose the safest possible way to try the other approach, and look
at the results.

5 - Do not listen to consulting experts, only to technical experts. The agile
manifesto is a nice reading, read it, think about it, try to follow, but don't
try too hard. Ignore any of the more detailed methodologies.

------
dwc
Much of the problem in the things you mention is that those things are
specific solutions that have been confused with goals. I.e., "we're supposed
to build microservices" is a horrible idea, as opposed to "given this
particular situation a microservice is a great fit".

Understanding the _possible_ benefits and drawbacks of any solution is
important. It's important in whether or not that solution is selected, but
also to make sure that the implementation actually delivers those benefits.

It's very common in our industry to use "best practices" without understanding
them, and therefore misapplying the solutions.

~~~
cookiecaper
As you've intimated, most people have a very superficial mental model.

Facebook == respected tech brand == someone I should copy. The end.

Guy I know uses Cassandra == developed by hot tech brand Facebook == cool by
mental association with Facebook.

Guy I know uses MSSQL or Oracle == developed by crusty old Evil Empire Company
that cool people don't want to work for == bad.

Conclusion: We must use "big data" so we can be like the cool people -- err,
because we really have some big data.

This doesn't sound like the outcome we'd expect from technical people making
these decisions, but we can obviously see that it's what we're getting.

------
kekub
I am working in huge non-IT company as a software developer. I guess that is
what gives me a totally different point of view on your lessons:

1) Without a unified technology stack and a common framework we would not be
able to build and maintain our applications. We decided on C# as it works best
for us. Currently we are 5 developers. Not a single one of us has ever written
a line of C# code before entering the company - learning the language from
ground up enables us to pick up patterns that our colleagues who joined the
company earlier found to be best practices.

2) If you are not introducing a whole new stack with every micro service that
you develop the devops costs are quite low.

3) I agree with you on that - I think redundancy always introduces more
complexity. However there are systems that handle that job quite well (e.g.
SQL Server). For application servers we use hot-spares and a load balancer
that only routes traffic to them, when the main servers are not reachable.
This works for us, as all our applications are low traffic applications.

4) Continuous integration works brilliant for our unified stack. In the last
two years we went down from 1d setup + 20min deploy to 10min setup + 20s
deploy.

5) We use agile methodology whenever possible and it works like a charm.
However we had a lot of learnings. Most recent example: Always have at least
one person from all your target groups in any meeting where you try to create
user-stories.

Planning our software architecture has been a key element in my teams success
and I do not see a point where we are going to cut it.

------
beat
1\. What problem are you optimizing for? "The job" encompasses code, but it
also encompasses staffing. It's a lot easier to hire Java developers than
Scala developers. In a leadership role, your responsibility isn't just the
day-to-day code - it's the whole project.

2\. Microservices vs monoliths is a see-saw. You build a monolith, find it's a
brittle, incomprehensible hairball, and you break out microservices. You build
microservices, find that operational headaches are killing you, and start
consolidating them into monoliths. Which kneecap do you want the bullet in?

3\. Fix what breaks.

4\. Continuous integration is _vital_. But it needs to be evolved along with
the system. There's this thing I say... "Have computers do what computers do
well, have humans do what humans do well". Handling complex and _repeatable_
behavior (i.e. builds and test suites) should absolutely be automated as much
as possible. Think continuous integration sucks? Try handing it off to humans
for a while! You'll learn whole new levels of pain.

5\. All process is about (or should be about) specific, discrete
communications issues.

~~~
misha67
> Which kneecap do you want the bullet in?

Funniest thing I've heard all day!

~~~
beat
That's the fun of working with me. I say funny shit!

I occasionally refer to the final steps of a project as "bayoneting the
wounded" too.

------
ChuckMcM
Yes we are over complicating it, but that it primarily about trying to take
what is essentially an artistic process and turning it into a regimented
process (a known hard problem).

Rob Gingell at Sun stated it as a form of uncertainty principal. He said, "You
can know what features are in a release or when the release will ship, but not
both." It captured the challenge of aspirational feature development where
someone says "we have to have feature X" and so you send a bunch of smart
engineers off to build it but there is no process by which you can start with
an empty main function and build it step by step into feature X.

That said, it got worse when we separated the user interface from the product
(browser / webserver). And you're rants about microservices and continuous
integration are really about releases, delivery, and QA. (the 'delivery time'
of Gingell's law above).

These are complexities introduced by delivery capabilities that enable
different constructions. The story on HN a few days about about the JS
graphics library is a good example of that. Instead of linking against a
library on your computer to deliver your application with graphics, we have
the capability of attaching to a web service with a browser and assembling _on
demand_ the set of APIs and functions needed for that combination of client
browser / OS. Its a great capability but to pull it off requires more moving
parts.

~~~
akamaozu
Link to the post about the graphics library please?

~~~
ChuckMcM
[https://news.ycombinator.com/item?id=13419665](https://news.ycombinator.com/item?id=13419665)

------
emeraldd
\- 1) Choose languages that developers are familiar with, not the best tool
for the job

95% of the time, a language that your developers are familiar with is the
correct tool for the job simply for that reason! There are cases where it is
not the case but those involve special case languages and special case
systems. If you don't know what special case means then you're situation is
almost certainly on that list.

\- 2) Avoid microservices where possible, the operational cost considering
devops is just immense

"If your data fits on one machine then you don't need hadoop ..." Same thing
applies here. Microservices have place and putting them in the wrong one will
bite you bad.

\- 3) Advanced reliability / redundancy even in critical systems ironically
seems to causes more downtime than it prevents due to the introduction of
complexity to dev & devops.

Then there's probably something wrong or limited with the deployment that
needs to be reviewed (2 node when you need a 3 node cluster, bad networking
environments, etc.) If you have a reasonable setup with solid tech under it,
_deployed per specs_ then this should not be true. If, on the other hand,
something is out of whack (say running a 2 node cluster with Linux HA and only
a single communication path between them) you're going to have problems and
the only way to fix them is to get it done right.

\- 4) Continuous integration seems to be a plaster on the problem of complex
devops introduced by microservices.

I'm not sure about this but, if your deployment system requires CI you have a
problem. An individual, given hardware and assets/code, should be able to spin
up a complete system on a fresh box cleanly and in a reasonable timeframe.
(Fresh data restores can take longer of course but the system should be
runnable barring that.) If this _requires_ (i.e. it can't reasonably be done
manually) something like an CI script or ansible/chef/etc. script then you're
deployment process is probably too complex and needs to be re-evaluated.

\- 5) Agile "methodology" when used as anything but a tool to solve specific,
discrete, communications issues is really problematic

Agile is commonly used to gloss over a complete lack of structured process or
a broken. Even with Agile there should be some clean process and design work
that goes into things or you're hosed.

~~~
jondumbau
4: if my stack requires a message broker to run, how is setting one up
manually supposed to be better to using the ansible scripts.

------
hd4
For me, the trinity of development as a solo developer seems to be:

1\. Writing code while using as many useful libraries and tools as possible to
avoid recreating wheels

2\. Continuous integration set up early on to handle the menial work and to
let me concentrate on 1.

3\. Constantly evaluating and researching what technology is available and
newly appearing to give me an edge, because having an edge is never a bad
thing in this field.

Agree with some of what OP said, especially with methodologies become
hindrances and HA tools becoming points of failure.

------
rb808
I've seen the addition of unit testing is a big cause of complexity.
Previously simple classes now have to be more abstracted in order to unit
test. Add mocks, testing classes & test frameworks. Some unit tests are handy,
but I dont think it justifies the additional complexity. For the apps I write
I'd like to see more emphasis on automated integration testing and fewer unit
tests - so we can write simple classes again.

~~~
julsonl
In my experience, it's usually not the existence of unit tests themselves
that's causing an issue, but that most of them are badly written. One telltale
sign is when writing the unit test becomes overly painful (like too much code
setting up mocks), it usually means that your class is not simple enough or
has too many dependencies.

Proper unit testing also complements integration testing in that corner cases
can be handled at the unit test level, therefore reducing the amount of
integration test code which arguably is much more brittle, runs slower and
more complicated to write.

~~~
jononor
Many unit tests are just written to test code, which is at best irrelevant. At
worst your codebase is 2-3x bigger and more abstract than it needs to, where
useless tests keep code alive and useless code keeps tests alive. Test
functionality, as close to the promises given to outside consumers as is
feasible. Be it API or UI for other people/projects/services. This is the
stuff that needs to work (and thus often need to be stable). No-one cares
whether a function deep down inside the code, used a part of the
implementation of promised functionality works. Delete it if you can.

Only case where I'd support "unit tests" as typically practiced (small units,
isolated functions/classes) is around _core_ competence (defined as narrowly
as possible). But then I'd argue that this functionality should be put into a
library anyways, which is used by products codebases. And then the tests are
tests for the functionality promised to the products.

~~~
julsonl
I'm not arguing against writing integration tests, they are as important if
not more important, as you've said. Maybe I've only seen badly written ones,
but my issue was against integration tests that check for example if this ever
so important, but hidden, flag is being set properly after an API call when
that can be checked at the service level. Someone eventually decides that flag
is unneeded, and a whole host of tests fail and someone has to dig several
levels deep to figure it out.

I guess I shouldn't have used the word 'brittle', but this is what I was
thinking of.

And of course, I think unit testing anything and everything is absurd and not
a good use of developer time.

~~~
Nomentatus
I don't think you can avoid meta-debugging. That is, debugging your asserts or
tests that you hoped would detect bugs instead of being the bug. Sometimes
because more realistic tests unveil a bug, sometimes (as in your example)
because underlying code functionality has changed. This is unavoidable but
also often enlightening. To my mind, it's even okay if most of your bugs are
meta - because these are usually very fast fixes, and it probably means you
have a lot of checks. But by the same token, I would agree with you that all
such tests have to be well-written, not mailed in, for just the reasons you
give. It's too easy to assume that writing tests is somehow a fairly trivial
task. Until you end up debugging the test.

------
jMyles
My first reaction to your (very thoughtful) review is that #4 seems out of
place.

CI _can be_ a way of enforcing the simplicity of the others - it can be a way
of tunneling the build process into assuredly straightforward steps and
preventing individual team members from arbitrarily (or even accidentally)
adding their own complications into build requirements.

Other than that, I think you are definitely on to something here.

------
adamnemecek
There's this book that I've been mentioning around here called Elements of
Programming [https://www.amazon.com/Elements-Programming-Alexander-
Stepan...](https://www.amazon.com/Elements-Programming-Alexander-
Stepanov/dp/032163537X/ref=as_li_ss_tl?ie=UTF8&sa-no-
redirect=1&linkCode=ll1&tag=akgg-20&linkId=66e61085fdce329bbcf6f12f2d180b57)
that makes exactly this claim, that we are writing too much code.

It proposes how to write C++-ish (it's an extremely minimal subset of C++
proper) code in a mathematical way that makes all your code terse. In this
talk, Sean Parent, at that time working on Adobe Photoshop, estimated that the
PS codebase could be reduced from 3,000,000 LOC to 30,000 LOC (=100x!!) if
they followed ideas from the book
[https://www.youtube.com/watch?v=4moyKUHApq4&t=39m30s](https://www.youtube.com/watch?v=4moyKUHApq4&t=39m30s)
Another point of his is that the explosion of written code we are seeing isn't
sustainable and that so much of this code is algorithms or data structures
with overlapping functionalities. As the codebases grow, and these
functionalities diverge even further, pulling the reigns in on the chaos
becomes gradually impossible. Bjarne Stroustrup (aka the C++ OG) gave this
book five stars on Amazon (in what is his one and only Amazon product review
lol).
[https://smile.amazon.com/review/R1MG7U1LR7FK6/](https://smile.amazon.com/review/R1MG7U1LR7FK6/)

This style might become dominant because it's only really possible in modern
successors of C++ such as Swift or Rust that have both "direct" access to
memory and type classes/traits/protocols, not so much in C++ itself (unless
debugging C++ template errors is your thing).

~~~
GregBuchholz
Have you looked in the STEPS program by Alan Kay? Trying to recreate modern
computing setup from the OS up in 20k lines of code...

[http://www.vpri.org/pdf/tr2012001_steps.pdf](http://www.vpri.org/pdf/tr2012001_steps.pdf)

"If computing is important -- for daily life, learning, business, national
defense, jobs, and more -- then qualitatively advancing computing is extremely
important. Fro example, many software systems today are made from millions to
hundreds of millions of lines of program code that is too large, complex and
fragile to be improved, fixed, or integrated. (One hundred million lines of
code at 50 lines per page is 5000 books of 400 pages each! This is beyond
humane scale.)

What if this could be made literally 1000 times smaller -- or more? And made
more powerful, clear, simple, and robust? This would bring one of the most
important technologies of our time from a state that is almost out of human
reach -- and dangerously close to being out of control -- back into human
scale."

...and of course if you haven't seen it, you'll want to check out the Forth
guys who want to do everything with 1000 times less code:

[http://www.ultratechnology.com/forth.htm](http://www.ultratechnology.com/forth.htm)

~~~
adamnemecek
I'm aware of this but Alan Kay's work and this seem to be orthogonal. Alan Kay
talks about reducing real systems that have compilers, inputs etc whereas
Elements talks about like the day to day ways of writing code. Alan Kay might
come up with a new keyword whose semantics magically lets you cut out 30% but
Elements shows you that if you make your types behave certain way, generics
will let you cut out a lot of code.

~~~
buzzybee
I would counter that this appears to be a repeatedly emerging consensus,
including Stepanov, Kay, Simonyi, and a number of other "greats", that an
approach that involves some degree of metaprogramming, guided by domain
problem, is the way forward. They differ on terms - cooperating systems,
model-driven, intentional, generic - and focus - whether to create new syntax,
or to guide the creation of specific algorithms or data structures - but they
aren't debating the power of the approach.

------
josephv
The only way to have any sense of a good or solid development platform or
lifecycle is, to me, to look at your specific situation and tailor everything
to your deliverables and needs. Doing anything because of industry trends or
academic pontificating will lead you towards the solution someone else had
success with in a different circumstance.

Microservices work fine in some situations, agile works fine in some
situations, but until you find that you are in one of those situations trying
to bend your deliverables to meet a sprint-cycle or some other nauseating
jargon will cause, as you put it, over-complication or just poorly targeted
effort. (It can also cause enough stress to dramatically affect your health, I
know better than most)

Those moments of solidarity between product and effort are real gems that I've
only recognized in hindsight.

------
solarhess
You are right. Agile, languages, CI, devops are all tools not solutions to
problems. Blindly applied, they will not get the results promised.

First focus on identifying the primary job to be done: build a valuable piece
of software with as little effort as possible given your current team and
existing technology.

Second, consider how valuable the existing software is and whether it really
needs to be rewritten at all. Prefer a course that retains the most existing
value. It is work you won't have to repeat.

Third, choose tools that maximize the value produced per hour of your team.
CI, Devops, Microservices, Languages all promise productivity and reliability
benefits but will incur complexity and time costs. Choosing the right mix is
part of the art of software management.

------
mhluongo
You're right, though you should end most of your comments with "for us".

We've been burned by the microservice hype, and it took a while for us to
realize that most of the touted benefits are for larger organizations. These
"best practices"" rarely include organizational context.

------
harwoodleon
Fatal problems that hit start ups seem left-field, but they are baked into the
design choices we make, often without discussion - because they seem part of
"current accepted wisdom".

My major issue for startup software development is that often software is
developed too discretely - with a utopian 'final version' in mind. Developers
don't think holistically enough - they focus on details at the expense of
design. "current accepted wisdom" is intangible, ever shifting, whereas the
failure of a system is very real and can lead to loss of income etc...

Lots of start up companies don't design systems with humans in them, they
write code as if it was a standalone thing - they often leave out the human
bits because they are hard to evaluate, measure and control - variety of
skill, ideas, approaches, mistakes, quality of life etc.

In my experience, this variety (life) often comes back to bite companies that
can't handle eventual variance because of poor system design - not because of
a choice of platform / provider / software etc.

I have been reading a lot around the viable system model (VSM) for organising
projects. It seems to fit with what my view on this is. I am trying to
implement a project using this model currently.

[https://en.wikipedia.org/wiki/Viable_system_model](https://en.wikipedia.org/wiki/Viable_system_model)

------
nojvek
As everyone is saying: do what is reasonable and useful.

E.g let's make an online shop.

It has browsing, purchasing and admin sections.

Browsing is simple. Query dB and show html. It's probably the most used as
well and needs to be reliable. Having as different service means admin section
could break while users are still able to browse. Same for payments. Sometimes
it's crazy complicated. I think of microservices as big product feature
boundaries that can work independently. A failure in one doesn't affect the
other.

Continuous integration: once you have your tests, and some auto deploy
scripts, you have an engine. You push code, tests auto run, a live staging is
created for latest code, you play with it. Looks good? Merge with Master. It's
deployed to production. The idea is deployment is effortless and you can do it
multiple times a day just like git push. Tests just don't only have to be
unit. We run integration testing features on dummy accounts periodically from
different regions in the world on production. This means you are alerted as
soon as something breaks. Fast deployment and great telemetry mean you can
always revert to last known good state easily.

Investing in tests is a pain but it pays off in the long run. Especially if
you have other developers working on same code base.

Just don't over do it. I believe these ideas came from pain developers
actually faced and they used then to solve it. If you're not feeling the pain
or won't feel it then you don't need the remedy.

------
TheAceOfHearts
I think in many cases complexity just comes from lack of experience and poorly
understood requirements.

I've had my fair share of cases where I ended up implementing something
needlessly complicated, only to later realize my approach was terribly
misguided. I'd like to think I'm slowly improving on this as time goes on.

The software world has a big discoverability problem. Even though I know
there's probably prior art of what I'm working on, I don't always know where
to look for it.

~~~
misha67
Honesty.

------
QuantumRoar
I think you wanted to say: "Are we simplifying things in software
development?" All of the points you have made are actually simplifications of
what might be the optimal solution.

Imagine the solution space as some multidimensional space where there is
somewhere an optimal solution. The dimensions include the habits of your
programmers, the problem you are trying to solve, and the phase of the moon.
Microservices, a special form of redundancy, continuous integration, agile
development are all extreme solutions to specific problems. Solutions which
are extreme in that they are somewhere in the corner of your multidimensional
solution space.

They are popular because they are radical in the way they conceptualize the
shape of the problem and attempt to solve it. Therefore they seem like optimal
solutions at first glance when really they only apply really well to specific
toy models.

Take e.g. microservices. Yes, it's really nice if you can split up your big
problem into small problems and define nice and clean interfaces. But it
becomes a liability if you need too much communication between the services,
up until the point where you merge your microservices back together in order
to take advantage of using shared memory.

Don't believe any claims that there is a categorically better way to do
everything. Most often, when you see an article about something like that, it
is "proved" by showing it solves a toy model very well. But actual problems
are rarely like toy models. Therefore the optimal solution to an actual
problem is never a definite answer from one of the "simplified corner case
scenarios" but it is actually just as complex as the problem you are trying to
solve.

------
solipsism
1) No way. Absolutely not. Not if what you're building is intended to last.
Any language/ecosystem you choose has costs and benefits. You will continue to
pay the costs (and reap the benefits) long after your developers could have
become fluent in a language.

Certainly the language your developers already know is better than one they
don't, all things being equal. But your rule is way too simplistic.

2) Of course. Avoid every complex thing where possible.

3) This means the cost/benefit ratio was not considered closely enough when
planning these features. Again, avoid every complex thing where possible.

4) this is a strange one. Most people doing CI are not building microservices.
CI is really more about whether you have different, independently moving
pieces that need to by integrated. Could be microservices, could be libraries,
could be hardware vs software. If you only have a single active branch
everyone's merging into regularly, you're doing CI implicitly. You just might
not need it automated.

5) take what you can from the wisdom of agile, and then use your own brain to
think. And don't confuse agile with scrum.

------
biztos
1) Sounds like there's a lot more to the story.

        * Was the "best tool" what the devs thought it was?

        * Was it something they would hate using? Say, Java for Perl devs?

        * Was there a steep learning curve? An obscure language?

2) How big is the system? How complex is the business? How ops-friendly are
the devs to start with?

3) You (or someone) must know how much system failure would cost.

4) CI can help with your devops, but its main point is to help with your
software quality. See #2.

5) Totally agree, though you can also try being agile about "Agile" and taking
just whatever parts work for you.

My $0.02 anyway.

(Aside: years ago I worked on a team doing ad-hoc semi-agile, which worked
pretty well. I'm 99% sure I could have double our output and launched a
management-consulting career if I could have credibly held the threat of Real
Corporate Agile Scrum over their heads. But that was before the flood. One of
them works for Atlassian now, ironically enough.)

------
msluyter
Though perhaps it's considered a component of 2), one could add
Docker/containerization. I've watched folks spend weeks and weeks getting
Docker setup for a service that probably didn't need to be containerized at
all. And then once it's Dockerized, introspection/debugging/etc... seem to
become much more difficult.

~~~
adictator
And what sort of services were those that didn't need to be containerized?

------
sydd
I agree with you, but not fully.

1) Well, this is only a case if the project is short enough that its not worth
switching. Learning a new tech for a team takes months, only switch if the
project is taking years.

2) Again, only use them for bigger (>2 years lifecycle) projects

3) Depends on what you need. We build a full stack apps with around 99.95%
uptime (a few hours of downtime/year) in around 3 months of architecture dev
time, this was good enough for us. Getting more would have hugely increased
dev time, but this number was good enough for us.

4) Disagree. You can build simple CI pipelines in a matter of weeks, which
will pay for themselves in a few months thanks to better uptimes, happier
employees, shorter release times. Again its only needed if your project lasts
for more than a year.

5) Disagree. Agile is very good, if someone knows it well (takes a few days to
learn). Its not needed for very small teams (<6 people), they can self-manage.

But I think there are problems:

\- People getting hyped about the latest trendy stuff. Use bleeding edge/new
tech for hobby projects not for money making.

\- Do not switch technologies unless really needed, dont fall for the hyped
library of the week.

\- Do not use a dynamic language for any project that will have more than 5K
LOC in its lifetime.

\- Do not overengineer. For example if the code is clean, works, but has that
ugly singleton pattern its OK. Dont introduce the latest fancy IOC framework,
just because you read it in the clean code book that its better.

\- Unit test are overhyped. Use them for critical components on the server,
and thats it. IMO the hype about them is because dynamic languages scale so
badly that you need test otherwise you're fucked. Rather choose a well proven
statically typed language, a good IDE, and take code reviews seriously.

------
yawz
"Perfection is Achieved Not When There Is Nothing More to Add, But When There
Is Nothing Left to Take Away" \- Antoine de Saint-Exupery

IMHO, it takes technical and personal maturity to come to the conclusion
above. Good architecture (or software or dev process or anything) should only
have/contain the simplest things that are necessary.

------
outworlder
> Avoid microservices where possible, the operational cost considering devops
> is just immense

Is it, though? There's more complexity due to more moving parts, sure. But
being able to solve issues by just issuing a "scale" kubernetes command in the
CLI is priceless. As is killing pods with no drama.

However, what are we talking about here? Small business ecommerce? Your
monolithic app is probably going to work just fine.

> Advanced reliability / redundancy even in critical systems ironically seems
> to causes more downtime than it prevents due to the introduction of
> complexity to dev & devops.

Systems can and will fail. If you can eat the downtime, by all means forget
about that.

> Continuous integration seems to be a plaster on the problem of complex
> devops introduced by microservices.

Could you stop singling-out microservices? We have deployed continuous
integration with old school rails apps before and it was extremely valuable.

Agree about agile.

~~~
cookiecaper
>Is it, though? There's more complexity due to more moving parts, sure. But
being able to solve issues by just issuing a "scale" kubernetes command in the
CLI is priceless. As is killing pods with no drama.

On the contrary, getting to the place where you can issue commands over k8s on
a project not specifically designed for it has a very real and very
significant cost. Companies are killing themselves trying to do this for no
good reason.

Need a new node? Fire up whatever it is that you fire up: Ansible, Chef, AMI,
bundle of custom bash scripts, whatever. No need for the _massive_ complexity
of k8s.

Specifically, what benefits are you seeing from k8s (i.e., what unique utility
does the "scale" or "delete pod" command bring that is not reasonably resolved
by less complex solutions)? It's just causing me a lot of frustration right
now. I can see Google's need for it. Not having much luck seeing its use in
non-Google-scale businesses.

If you're doing a from-scratch thing that you can architect around k8s and
think that's more convenient than more traditional approaches and can accept
its currently-quite-serious limitations, that's whatever. If you're talking
about some tangible objective benefit that most companies need to be able to
enjoy here, please do elaborate.

------
apeace
I think #5 is the most problematic here, and was stated perfectly.

One method I have used successfully is sending surveys to people outside
engineering. Send it to department heads and anyone else who seems interested
in what engineering does. Ask them if they feel engineering is transparent,
and whether they feel important bugs/features get followed up on. Let the
responses guide you, and make the minimal process changes you need to in order
to satisfy people's real concerns.

One other piece of advice: if certain people seem obsessed with process, it's
possible they are poisonous to your whole organization and should be let go.
Some people want process to be there to give them work (e.g. "managing the
backlog" or "writing stories"), instead of doing actual work like programming
or product research.

------
conradfr
As someone working at a Scrum company transitioning from PHP "monoliths" to
DDD microservices shielded by nodejs gateways and apis and even CQRS/ES on the
horizon I will answer yes.

But I guess that'll look cool in our resumes.

I must say sometimes I envy our mobile developers that are a bit immune from
all that.

------
feyn
Too much to say, so I did a blog post:
[https://neilonsoftware.com/2017/01/18/my-response-to-are-
we-...](https://neilonsoftware.com/2017/01/18/my-response-to-are-we-over-
complicating-software-development/)

------
alex_hitchins
I agree with most of your comments. I think as a fairly new profession we are
still finding our feet when it comes to best practices. I don't think there is
one system that will work across the board for all trades. I mean I would
think it took longer than 30-40 years to work out the best way to plumb, wire
a house etc.

Sometimes when estimating work, I think how long would the same project take
to build 5, 10, 15 years ago. It's not often that time spent coding today is
any quicker than before.

Arguably we get better quality software now with unit tests, better compilers
and better tooling. Perhaps I've just got some massive rose tinted glasses
on!.

------
hacker_9
All problems revolve around structure, and as customers want more features,
and capital builds, the structures get more complex. So we build even more
complex structures to offset the complexity, but now things that were once
simple get brought along and become more complex. Eventually the company hits
a breaking point and re-invents it's structures to better suit their needs,
but these grow in complexity once again given time. It is a never ending
battle, and every business is at a different point in their complexity cycle.

------
contingencies
Choose languages _and_ frameworks that developers are familiar with.

Microservices are fine if you can rely on shared CI/CD infrastructure and
automate execution properly, maintaining rapid build/test cycle times. They
start to suck if people aren't familiar and everyone's laptop has to hold
their own parallel multi-topology service prom regression test (^releases)
every time you change a line of code... developer focus, flow and efficacy
will be reduced.

I agree that redundant HA systems are usually not required. In the past it was
expensive to get. However, tooling is now so good that with reasonable
developers and reasonable infrastructure design, you can get it very, very
cheaply if your services are packaged reasonably (CD-capable) with basically
sane architecture and your infrastructure is halfway modern. This truly is
excellent, because gone are the 1990s of everyone-relies-on-grizzled-sysadmin-
and-two-overpriced-boxes-with-failover.

I don't think CI is a plaster, it is a great way to work, but like any tool or
workflow is not appropriate in all situations.

We do over-complicate. Methodologies are too meta: programmers are already
operating at max concurrent levels of abstraction. Better to incrementally
adjust workflow (CI/CD on the workflow for the CI/CD of the workflow!). That's
not to say that there's no value to some people thinking at this level some of
the time, but Yoda told me "desk with agile literature much, sign of untidy
mind be". I think he was right.

------
Azkar
I feel like all of this just comes back to judgement calls. You can't pick
technologies in a vacuum, and you can't generalize technology choices.

It's not very fair to make these claims without knowing all of the details
around the situation. Microservices CAN be a pain, but it might offset a
greater pain of trying to coordinate a monolithic deployment. It depends on
things like team size, budget, and technology available to you.

This is where I see the disconnect between employers and most developers.
"Programming" isn't a job. Your employer doesn't pay you to write code. They
pay you to solve problems. The good employers don't care what tools you use to
solve the problem, just that you solved it. The bad employers will force you
to use technologies and buzzwords that probably don't apply to your situation.
You should be able to defend all of your decisions and have good reasons for
them.

On the flip side, not everything you try will work - that doesn't mean that
it's a bad option, just that it didn't work for your situation. You don't need
to have a redundant low-priority memo system because you don't get enough
value out of it to justify the overhead of maintaining it.

------
peterwwillis
I think you confused trends for wisdom.

It used to be wise to wear bell bottom jeans and perm your hair. It also used
to be wise to wear colored suspenders, or pocket protectors. And shoes with
lights in them, and color changing shirts.

Granted, those same weird misguided trends were probably followed by the same
people who accomplished everything we have today. I think it's the effort you
put into the work that determines its output, not the details of its
development.

------
lolive
Point 5 is really insightful. When you read it carefully, it implies that
agile "methodology" will soon become the prevalent methodology. Because a
successful project is all about managing a massive amount of "specific,
discrete, communications issues". And doing so on a daily basis is the best
option.

Off-topic note: point 5 is also the way to go with your
wife/husband/girlfriend/boyfriend, your kids, your friends, etc.

~~~
js8
Interesting idea. I think dinner is the best place for an evening family SCRUM
meeting.

~~~
lolive
SCRUM meetings with cheese and wine. THIS - IS - BRI-LLI-ANT !!!

------
cthulhuology
Honestly, it is probably just you (and your peers).

Quite frankly chances are the team you have sucks at operations, lacks the
necessary experience to design complex systems, and probably doesn't do the
fundamental engineering to make a reliable software product.

1 - false dichotomy, the best tool is one you have mastered, your team has
individuals with 20+ years of development experience on it right? (Probably
not)

2 - micro services are supposed to have small areas of concern and small
functional domains to minimize operational complexity. Your services are
programs that fit on a couple screens right? (Doesn't sound like it)

3 - redundancy's goal is to remove single points of failure, you should be
able to kill any process and the system keeps working. (The word critical
suggests you have spfs)

4 - CI is a dev tool to avoid merge hell by always be merging. CI is often
used by orgs with massive monoliths because of the cost of testing small
changes, and too many cook trying to share a pot. Ultimately if you don't have
well defined interfaces ci won't save you. (You had well defined published
interfaces with versions right?)

5 - agile is a marketing term for consulting services to teach large orgs how
to act like small effective teams of experts. (Hint you need a team of self-
directed experts with a common vision and freedom to execute it, you got that
right?)

Most problems in tech are related to pop culture. Because we discount
experience (because experienced developers are "expensive") we get to watch
people reinvent existing things poorly. Microservices, soa, agile, ci, these
things are older than many devs working today. The industry fads are largely
just rebranding of old concepts to sell them to another clueless generation.

Computers are complex systems, networks of computers are complex systems.
Complex systems are complex. Some complexity is irreducible, and complex
system behavior is more than just a mere aggregation of the parts. People tend
to over complicate their solutions when they don't understand their actual
problem. They see things they are unfamiliar with as costly and overly
complicated (as in your examples above).

Your problem is a culture that doesn't value experience and deep
understanding. You and your team will over complicate things because you don't
know better yet.

------
virgilp
1) Yes, except that you should try some languages sometimes. E.g. if you use
Spark in production as a critical part of your system... take the time to
learn scala.

2) Is a pet peeve of mine. Theoretically microservices are good, but we don't
have a way to orchestrate them. What's lacking (in programming languages
terms) is a "runtime" and "debugger" and of course a widely-tested & reliable
set of "libraries" for most common tasks. I think it's possible to do
something like that, as long as you start imposing some restrictions on what a
"microservice" is and how it talks to the outside world. Also, in this frame
of thinking, it becomes apparent that "deployment" is actually "programming
the system, at a high level". It's not "just configuration", configuration is
code - if you moved the complexity from your "code" to your configuration, you
just moved the complexity into a language that has very poor tools to work
with.

3) My rule of thumb for most systems is "avoid redundancy in the control
plane; you can and should have redundancy in the data/data processing plane;
don't plan for 100% uptime in the control plane, plan for very short
downtimes/ for fast recovery when something goes wrong"

4) My experience is that continuous integration is good for all but the very
small teams. For multiple reasons, not just "microservices"

5) "Agile" is horrendously misused, the cargo cult is in full force. It should
be about prioritising & doing the important things, reducing overhead to the
minimum necessary. It has become an overhead in itself, with "sprints" reduced
to ridiculously low periods, meeting over meeting at each sprint, etc.

------
6DM
I think micro-services was your big issue. But yes, getting into the politics
of pure scrum, kanban, whatever is a big drag.

DevOps has it's merits and will work well if you're team can stop trying to
develop newer better scripts and learn when to say it's good enough. I saw one
team revise their scripts over and over for a whole year when they could have
been using that guy for new features/bug fixes.

------
halis
1) Choosing JavaScript for a Math heavy project would likely be a mistake.
There are plenty of other examples of picking the wrong language for the wrong
job. That's where this statement falls apart.

2) Depending on how you bring them all together, yes this can be true. If you
have something like AWS API Gateway, then microservices may be manageable. If
you're rolling your own custom solution with something like nginx or haproxy,
you're probably wasting a ton of cycles.

3) Again, I tend to agree with this. Premature optimization seems to be the
norm these days. Especially when you get devops people involved. Do we need
every single layer in our stack to be "highly available" if we have zero
users? The answer is NO.

4) Well, this sounds clever, but I'm not sure it really means anything.
Setting up something like Jenkins to watch your GitHub repos and build the
branch and run the tests can alert you to issues early and really isn't that
difficult to setup.

5) Nothing wrong with TDD as long as you don't go overboard. Nothing wrong
with standups, planning or retros. Nothing wrong with short sprints.

------
YZF
The rule is there are no rules. The answer is "it depends".

If the only language your developers are familiar with is Ruby and you're
developing a real-time, high-performance, system, then you shouldn't write it
in Ruby.

If you need the kind of availability/scalability/encapsulation that
microservices provide in your application/use-case then you should use them.
Don't break you application into micro-services just because everyone says
it's a good idea. An Angry Birds app on an iPhone doesn't need to be split up
into micro-services running on said iPhone.

If you don't have redundancy and you lose your server then you're hard down.
If you're OK with that fine. If you want to continue operation with one server
down then you need redundancy. Redundancy doesn't necessarily add as much
complexity as you seem to imply.

Continuous Integration is usually a good idea regardless of all other
variables. If you have more than a single developer working on a system it's a
good idea to keep building/testing this system with every change so you can
catch issues earlier. You start very light-weight though with a small team.
Even a single dev can do CI, it's not that hard.

Agile is just a buzzword but it doesn't hurt to familiarize yourself with the
Agile Manifesto while making sure you're aware of the context in which it
arose. It's really mostly about understanding that requirements often change
and that we're dealing with humans. Again different projects, team sizes,
situations will require somewhat different approaches. Sometimes the
requirements are well understood and will change very little. Sometimes you
know nothing about what the software will do when you're done.

------
MaulingMonkey
A certain amount of complexity or complication is required to solve problems.
Sometimes, you will undershoot the mark, and not fully solve the problem.
Other times, you will overshoot the mark, and create problems in the form of
overcomplicated answers.

> 1) Choose languages that developers are familiar with, not the best tool for
> the job

It's a tradeoff - rampup time vs efficacy once ramped up. It's probably okay
to let your devs rock it old school with vanilla Javascript for your website
frontend - it's probably _not_ okay for them to try and write your website
frontend in COBOL, even if CobolScript is apparently a thing, just because
they don't know Javascript.

> 4) Continuous integration seems to be a plaster on the problem of complex
> devops introduced by microservices.

CI is great plaster for all kinds of problems, not all of which you'll be able
to solve in a reasonable fashion. Of course, you may have problems which would
be better to solve that you're using CI as a crutch to avoid solving - or to
simply deal with the fact that you haven't gotten around to solving those
problems _yet_.

In game development, I use CI to help 'solve' the problem of my coworkers not
thoroughly testing all combinations of build configurations and platforms for
each change. 5 configs and 6 platforms? That's already 30 combinations to
test, so it's no wonder...

> 5) Agile "methodology" when used as anything but a tool to solve specific,
> discrete, communications issues is really problematic

On the other hand, other companies rock "flat" management well past the point
it's effective, and may lack any kind of methodology to keep progress on track
- which is also problematic.

------
kingsawlamoo34
Why not all peoples are searching actual software?Its so difficult how many
years in making system anyone cannot knowing of all of app or platform or app
or plug in or device or codechar all things are supporting each other if one
app is not update directdownload from google play store,windos for microsoft
store how to give the part way of moving simple all App or Apk have in their
basic code ID company .how about they making of you will be use one app or apk
and then you sign out App and delete software but your using activity remain
in more sure you can next time you reuse same app you will be seen or not your
history this is one things but alittle difference in fre game app how about
you play inside but you will be exit and then you replay this you can see or
not your recent play section if you make log in account connect sure you can
making or not resume game section game.all of game have in prevent and resume
section already contain but you are not own create you cannot open this
background codechar or security for example...

------
steven777400
Keep in mind, as others have said, the "accepted wisdom" is coming out of
high-income, high-velocity, technology companies. However, a lot of
development is done at companies whose primary business is not software (or
not technology). Additionally, many established businesses care less about
velocity than hungry startups.

In that case, I think a different set of wisdom applies: 1\. Choose languages
that are easy to hire for, easy to train for, have lots of 3rd party support,
and easy for junior developers to use (and that your developers already know).
This generally means Java, C#, or Python (on the backend)

5\. First it's important to define "agile" in your context. Agile, in terms of
the agile manifesto, is almost always beneficial to the project, although it
won't speed it up. Agile, in terms of cargo culting specific artifacts, is
often just a waste of time and source of confusion. If your organizational
definition of agile is "no project manager needed", then you're in trouble.
Good project managers are essential.

------
buzzybee
There's a great discussion to be had in scaling your practices to the human
factors.

For a solo developer, just breaking things out into modules and massaging the
formatting is likely to be a net negative - something you might do once you've
accumulated months of cruft and are ready to start handing it off to others or
repurposing it for a new project, but also a chore that will get in the way of
thinking about the job in front of you _right now_ , a temptation to think
top-down planning will come to your rescue. Your advantage is in being able to
change direction immediately, and there are a lot of ways to give that up by
accidentally following a practice for a larger team.

As a team gets bigger, it's more important to be cautious because of momentum;
any direction you pick for development will be hard to stop once it gets
going.

At the same time, there are processes and automations that help at every
scale, and at the small scale they're just more likely to be little scripts
and workflow conventions, not ironclad enforcements.

------
StreamBright
Well, I think there are 6 points to answer here:

>> 0, Are we over complicating software development?

Yes, in many cases we are over complicating software development. I think a
large part of OOP too complex to produce reliable services easily, still
possible though. Simplicity is not as popular among developers as it should
be. I often run into complex code that can be replaced by 10x smaller code
base that is much clearer than the original.

1, Sure

2, I am not sure why you think that, you need services that can few things
well and individually scalable units. This used to be SOA (service oriented
architecture), and micro-services lately. There are cloud vendors out there
who make it super easy for you to run such services for reasonable price on
their platforms without a devops team.

3, See point 0. Complex systems fail more than simple ones. Failure isolation
and graceful degradation should be properties at design time. The best is to
have stateless (no master slave service or registry that is required for
correct operations) clusters where you can scale the capacity with the number
of nodes.

4, Continuous integration is way older than the term microservices. It
contains patterns that a company figured out by shipping code that had to be
reliable and it is optimised for frequent changes aka when you developing a
new service or product. It is just a way of giving instant feedback to
developers.

5, There are so many talks and videos about agile used bluntly is harmful on
the web that I think this is a well understood question. Use a method that
works for the team, it provides the insight to the business what they are
doing and you are good. I use Kanban for almost 10 years with distributed
teams (software and systems engineering) and it works perfectly for us.

+1 for simpler code and simpler software

~~~
dceddia
Re: #2, what are some such services?

AWS seems to be the go-to standard but it's amazingly complicated.

------
Sammi
You are basically say much of the same as Dan North is saying in his newest
take on Agile:
[https://www.youtube.com/watch?v=iFLBG_bilrg](https://www.youtube.com/watch?v=iFLBG_bilrg)

Agile is dead, long live Agile. The difference now, is that we understand
trade-offs. There's no silver bullet and there are no absolutes.

~~~
Yhippa
Did people honestly think that Agile was going to be a silver bullet? If so
the consultants won.

------
rymohr
Can't agree enough!

I actually wrote an article [1] last week exploring single-tenant SAAS
architectures because I was annoyed with how complicated our multi-tenant
plans were. Was bummed the HN post [2] didn't get any traction because I was
really hoping for some critical feedback.

For me, the holy grail is a cost-effective system that doesn't back you into
scaling issues down the road and is simple enough to be run by a single
developer (on the side) rather than a dedicated team of sysadmins. Pipe dream?
Maybe. But it's worth a shot.

[1]: [https://hackernoon.com/exploring-single-tenant-
architectures...](https://hackernoon.com/exploring-single-tenant-
architectures-57c64e99eece)

[2]:
[https://news.ycombinator.com/item?id=13385474](https://news.ycombinator.com/item?id=13385474)

------
grok2
From what you are describing, it seems like there is more a problem associated
with your team than with anything else. Maybe you don't have the right set of
expertise in the team and people tend to work better with what they are
comfortable with. Microservices/redundancy support/CI at a fundamental level
increase the complexity of how you go about things, but they do have benefits.
They require a way of thinking and developing that should be a cultural fit
for the team for it not to feel like you are constantly fighting the system.
One way to get there is to incrementally add these after the primary project
is done. When tackling one thing at a time, things end up being simpler and
and the need for these things gets into the working habits of everyone better
and they are no longer fighting the system.

------
buro9
devops is good stuff. Just apply to the developers the same standards (and
typically answers) as you would to your deployment world. You should be able
to answer questions like: "How does a new developer get going within 5
minutes?" in the same way that you answer "How do we build and deploy a new
app?" and both the local developer and remote system should be debugged and
monitored in the same way.

devops isn't bad, and will speed up onboarding new staff, growing, and helps
your devs and ops people immensely.

On the rest I'd largely agree with you... other answers may only apply at a
certain scale, or complexity, or some other set of parameters that may not
apply to you now.

Solve the problem you have now, and the problem you'll definitely have in the
next 6 months.

The rest is for the future.

------
vcool07
You need to work in an environment devoid of any practices like agile / CI etc
and then you would know the difference. It might slow down your progress, but
makes up for it with consistency, discipline eventually leading to development
of better(reliable) software !

------
zitterbewegung
If you keep on following every hype-train yea you will get over complicated
software development.

------
seangrogg
From my perspective, the problem is that others _believe_ everyone else is
caught up in the same trends they are. If someone starts to prosthelytize
something - whether that's build management, microservices, or even pairing
React with Redux by default - individuals start to think it's the "new thing"
and adopt rather than critically think about it.

Personally, I tend to shy away from tools unless they seem to do something of
significant value for me that outweighs their cost on my development process.
The "best tool for the job" is the one that allows me to finish a project in a
timely manner, not one whose memory footprint is 10% lower.

------
Ericson2314
It's all about long-term vs short-term. _Everyone_ architects software for the
short term, I'd say the industry at large has collectively lost/never had the
vision and wisdom to do anything else.

Now maybe if you are a tiny-ass start-up, sure, but for a big established
company, this is just bad economics.

Why do we talk about "disrupting" the "behemoths"? Why is everything done in
tiny-ass largely-parallel teams? Very few companies have had serious thoughts
about programming at scale.

I don't dispute that doing things the right way is often a huge up-front
initial investment, but you do eventually get over the hump.

~~~
flukus
> Everyone architects software for the short term, I'd say the industry at
> large has collectively lost/never had the vision and wisdom to do anything
> else.

I think everyone architects for the long term, they just do so poorly. The
problem is that architecture has become synonymous with "more layers".

~~~
Ericson2314
OK, so in the beginning there were no layers. People occasionally wrote a
layer but it was common to just say "fuck it", and through it away. As late as
the 90s, you read about C programmers writing hash tables all the time, wtf.

Then, somewhere along the way I don't know exactly when, we hit an inflection
point where there were some layers that didn't work quite right, but were hard
to do without, so we'd try to shim it.

Really good long-term engineering means also ripping up the under-performing
layers, attacking the unneeded complexity. This does not mean giving up on
abstractions altogether.

------
oblio
Continuous Integration on any project which will be developed for more than 1
year by more than 1 person should provide a positive return of investment.

The rest are debatable, but I feel that the point above is close to an axiom
these days.

------
Animats
I've used microservices, but on QNX, where you have MsgSend and MsgReceive,
which make message passing not much harder than a subroutine call, and not
much slower. UNIX/Linux was never designed for interprocess communication. You
have to build several more layers before you can talk, and the result is
clunky.

If you're crossing a language boundary, it's often better to use interprocess
communication than to try to get two languages to play together in the same
address space. That tends to create technical debt, because now two disparate
systems have to be kept in sync.

------
zzzcpan
I think these problems are not about software development, but are
infrastructural and architectural. Lack of good people to handle those things
is certainly a problem. But you do need quite a bit of infrastructure for
microservices, for resilience, for continuous integration and all of that
paired with some good architectural decisions. Resilience is probably the
hardest thing among them, as it requires some expertise in distributed
systems, operations, infrastructure, so you wouldn't do something, that has
almost no impact, but requires a lot of engineering effort.

------
protomyth
At this point, I think a lot of software development problems are complicated
because we are building on a platform that really isn't designed for the apps
we want. The web makes everything a lot more frustrating and hard. It
complicates testing and requires a lot more process than is justified by the
apps. At some point the era of the web will come to and end then maybe we will
get a net gui (probably based on messaging) that will hopefully take the
lessons of the web to heart.

------
makmanalp
I think this is where a lot of varied work experience (small / large / old /
new companies) is key, because it gives you perspective. You can then ask
yourself, "why does this process suck so much, and why didn't it when I worked
at X? In my experience, people who come from a monoculture background usually
seem to not question dubious software, architecture and methodology choices
that end up killing productivity and sanity.

~~~
AnimalMuppet
Yeah. If you're going to use languages, methodologies, and architectures
without understanding, and without evaluating them for how well they fit your
situation, many things will be painful. Don't follow the fads, whether
methodologies (Agile), architecture (microservices), languages, or frameworks.
_Use what 's appropriate for what you need to do._

------
raverbashing
1) The best tool is useless if people can't avail of its power

2) True. Microservices are usually premature optimization

3) True

4) CI is a good idea regardless of using microservices or not

5) You might elaborate this item

------
chetanahuja
No it's not just you. In general, "follow latest trends blindly" has never
been a winning strategy in software development at any point in computing
history. Now, that is not to say that you never change your tools or
methodologies once you've mastered your existing tools. But the new
tools/techs need to pass a very high bar before you subject your team to
these.

------
wickedlogic
Yes, we are over complicating software development.

------
mybrid
Another way of saying this is it is not science.

Usability needs to be applied to more than just the end user experience: but
the entire SDLC experience.

------
rb808
The biggest issue I have is the current fashion for functional languages
resulting in mixed style code bases. I've been working on established
applications written in Java/C#/Python that have OO, imperative and now
functional code all mixed together.

If I had it my way we'd choose one or the other but no one can agree which is
the best way to write code.

~~~
nathanaldensr
The style takes a backseat to readability and maintainability. Try creating
complex object queries in .NET without LINQ; good luck at reading and
maintaining that code. I'll take my lambda expressions any day over that,
thank you. I remember "the good old days" of C# 1.0 and you'd be crazy to want
to go back there.

------
bluestreak
It isn't new when I say that it is hard to come up with simple solution.

In most cases people tend to work under pressure, which ends up with problem
nicely fitted to tool at hand. You can hardly blame anybody for that. What we
are not doing enough is going over "solution" again and again. Solving a
problem second time around is always easier.

------
bjourne
Yes. What you have discovered is the same epiphany most developers have as
they get more experienced and better at their jobs.

------
swift
I'd like to push back on continuous integration being over-complicated. It's
easy to do using off-the-shelf software and it makes life a _lot_ less
stressful when you have confidence that your changes are good before landing
them in production. It's such a win that I'd set it up even with a 10 person
team.

~~~
nathanaldensr
I use TeamCity to automate running my unit tests and generating/publishing
NuGet packages to my private NuGet server... and I work alone. It has value
even there. :)

------
koolba
> 1) Choose languages that developers are familiar with, not the best tool for
> the job

The language that you're familiar with generally is the best tool for the job.
Most software work can be equally done well (or at least greater than
acceptably well) in a number of languages. Not having to learn a new one (or a
new framework) is a plus.

------
Gurrewe
All development teams or products are not the same. Sometimes microservices
can improve the quality, and sometimes the opposite.

It is important to know why you do some things, instead of applying Hype-
Driven-Development.

Do what is best for _you and your team_ , instead of what is best for _someone
else_ (with a different product, problem, and team).

------
lukaszkups
Are You a front-end developer? :D

Yes, I think very often we over complicate even simple things. But sometimes
it pays in the long run.

------
pmontra
Most of the time we're creating complexity when we can avoid it and we're
often proud of it.

The problem is that's very difficult to find the right compromise between
time, cost, an architecture that can support the growth of the service so
either we build something too thin or something too complicated.

------
greyman
Continuous integration is also necessary for bigger projects with many inter-
dependent parts. I worked in such a project, we had about 100 developers on it
and I just can't imagine how it could be efficiently developed without CI. But
for small projects it maybe isn't that critical.

------
agentultra
Just linking my comment to the other thread in response to this post:

[https://news.ycombinator.com/item?id=13429618](https://news.ycombinator.com/item?id=13429618)

tldr; simplicity is a great virtue and difficult to achieve in practice.

------
bassman9000
Could also be interpreted as: "devops is not yet mature/lacking tooling".

Don't get me wrong, complexity has grown. Agile is a joke. But, e.g., build
systems have been maturing for 30+ years. Their cousins, deploy systems, have
a long way to go.

------
corecoder
Always worth mentioning: [http://thedailywtf.com/articles/Programming-
Sucks!-Or-At-Lea...](http://thedailywtf.com/articles/Programming-Sucks!-Or-At-
Least,-It-Ought-To-)

------
eikenberry
> 1) Choose languages that developers are familiar with, not the best tool for
> the job

+1

Programmers have affinities for languages. They will work better with some
languages than others and they know which languages fit them well. Those are
the best ones to use.

------
mbrodersen
No you are absolutely right. 95% of problems in software development are
created by the software developers themselves. At least that is my experience
having worked in software for 20+ years in companies all over the world.

------
joelthelion
I think one cause of the problems is that what is good at Google scale is not
necessarily relevant for a team of ten people.

I think the lesson here is be critical of "best practices" and think about
what will work in YOUR context.

------
tboyd47
You are correct. We cargo-cult Google and Facebook so much that we forget to
apply lessons learned decades ago. People and interactions over processes and
tools. There is no silver bullet. You Ain't Gonna Need It.

------
usgroup
... I'd agree. Put briefly, if you're trying to save the day, people first.

But when you stop needing to save the day and want to build something will
particular properties , you may find that process has to come first.

------
user5994461
So... that big list is the lessons learnt at the startup IR the big company?
Its really not clear to me.

Same problem with all the comments that begin with "at my last company". Which
kind was it?

------
jasonlotito
> lack of communication

You can't talk about lack of communication and blame "devops" at the same
time. If there was a lack of communication, you aren't "doing devops."

------
camus2
1/ What language did they choose? why? what made them think language X or
framework Z would give them a competitive advantage at first place and what
was the result of that choice?

------
dood
The issue is that solving real problems is hard, but making things complicated
is easy, fun, and looks a lot like solving real problems if you aren't paying
careful attention.

------
sapeien
1) Doesn't always work if you want to target embedded systems or need
performance, and all you know are scripting languages with huge overhead like
Ruby, JS, Python, etc. Some languages really are better than others.

2) Could say avoid distributed computing if your problem is not distributed.
This is more about being a blind follower of the latest hype.

3 & 4) Complicated DevOps are a bad idea in general. Stuff that seems to
simplify things on the surface like Docker are actually hiding tons of
complexity underneath.

5) To most people, Agile = JIRA = Sprints = Scrum. It's corporate mentality
codified, so it's no surprise that a lot of startups avoid it.

------
GnarfGnarf
Software development goes off the rails because there are no physical
materials involved, so there is no built-in limitation to prevent costs from
going out of control.

------
d--b
truth is: you're young and you're becoming an experienced developer... You
somehow have to go through these stages. In the end, you'll be all right.

------
pknerd
Some people have got so used to of complicated architecture and workflow that
they are finding your questions odd. Just check comments.

------
TurboHaskal
Hey, we gotta eat. If people won't pay for software licenses then we'll make
them pay for training and consulting services.

------
devdad
Hi, I'm happy to be posting anon right now. Can someone ELI5 the difference
between libraries and packages and a microservice?

------
graphememes
I have seen Microservices be the death of a lot of startups / corporations.
Proceed with caution.

------
z3t4
i think the best way is to start backwards in the future. what are the
requirements. then plan towards today. what do you need and when ... thats how
i did plan my training program as an athlete. the most important question is
what do i need (to do) right now

------
r4ltman
as a guy whose idea was successfully pitched to a successful tech company of
which i am still connected, i'm going to say yes. the classification aspects
of specialty training keeps the process from being as fluid as it needs to be
in order to be truly game changing rather than merely, whatever expectation is
expected.

i know this sounds different to everyone, here's the point,

The User Needs to Use It. The focus is always on everything else. Only when
theres' been 'some' success does the user and by user, I mean, the entire
field the program is for, is an influence, this lack of empathy keeps any
leadership from ever happening when everything is based on 'past successes of
other companies' rather than trying to lead effectively.

------
jbverschoor
YES!

------
madhadron
Figuring out how to do things simply is remarkably hard. After twenty years of
this, I feel like I'm beginning to be able to design simple systems some of
the time.

The problem with much "currently accepted wisdom" is that it doesn't explain
exactly what is being balanced. "Works for my organization" is the equivalent
of "works on my machine." For example,

1) "Best tool for the job" when applied to languages nearly never is a
question of the intrinsic merits of a language design. There have been quite a
few discussions recently on Hacker News on the virtues of a boring stack, that
is, one that everyone else has already beaten on so much that you can expect
to hit fewer issues.

2) Microservices are a tradeoff. If you have an engineering team of five
hundred shipping a single software as a service product, one of your biggest
issues is coordinating releases among all those people without having your
services ping-ponging up and down all the time. Microservices are an answer to
that. At that scale you've already had to automate your operational troubles,
so it doesn't impose that much additional operational cost. If you have an
engineering team of ten, then none of this applies to you.

3) High availability, like all concurrency, is hard. Try to write your own
code so that it scales horizontally by simple replication and depends on stock
components such as Kafka, Zookeeper, etcd, or Cassandra to handle
orchestration. In many cases your reliability budget may be such that you can
run a single system, automate some operations around it, and be just fine.
It's only when your reliability budget doesn't allow that, or your workload
forces you to orchestrate parallel work, that you have to go this route.

4) Yes. Nearly all discussion of agile software development that I've seen
focuses on rituals without the applied behavior analysis underlying them. For
example, a standup meeting has a small set of goals: establish a human
connection between everyone on the team on a regular basis; air things that
are blocking individuals in a forum where they are likely to find someone who
can unblock them quickly; have everyone stand up and take responsibility for
what they are doing in front of their team; and serve as a high bandwidth
channel of communication of important information (the build is going to break
this afternoon for an hour, etc.). If those outcomes are being achieved in
other ways by your group, then there's no reason to have a standup. If you're
doing a standup and it's not accomplishing one or more, you need to revise how
you do it. Human behavior and interaction is something to be designed and
shaped in an organization. What works in a team of three with excellent
communication may not work in a team of ten or fifty or five hundred.

------
lngnmn
_looking at some react-todo-demo and its dependencies_ \- complicating? not at
all!

J2EE will soon look like a reasonable thing.

------
siphr
YES WE ARE-

------
shitgoose
it is not just you, but we are hopelessly outnumbered.

------
btilly
There is a lot of BS in software development. Always has been, probably always
will. Everything is a tradeoff. Understand the tradeoffs that you are taking,
listen for the principles, and you can ignore most of the noise.

On to your questions.

 _1) Choose languages that developers are familiar with, not the best tool for
the job_

How familiar developers are with the language is part of what determines what
is best for the job at hand in a real organization.

It isn't the only factor. For example if you're doing something new (to you),
doing it in the language that you find wherever you are learning it from makes
sense because you'll be more likely to get help through complex issues.

That said, do not underestimate the support advantage of using a consistent
toolset that everyone understands.

 _2) Avoid microservices where possible, the operational cost considering
devops is just immense_

See
[https://martinfowler.com/bliki/MonolithFirst.html](https://martinfowler.com/bliki/MonolithFirst.html)
for emphatic support.

If you go the microservices route, think ahead about predictable challenges
with debugging failures 3 calls deep, and plan in advance for monitoring etc
tooling to solve it.

 _3) Advanced reliability / redundancy even in critical systems ironically
seems to causes more downtime than it prevents due to the introduction of
complexity to dev & devops._

As the old saying goes, DBAs are the primary cause of databases going down.
Reliability is not something that you just plaster on top blindly. An systems
are good at finding failure modes that you never thought of.

 _4) Continuous integration seems to be a plaster on the problem of complex
devops introduced by microservices._

No. Continuous integration is actually a fix for developers checking in
clearly broken code and then nobody discovering it later. That said, it does
little good without a number of other good practices that are easy to ignore.

 _5) Agile "methodology" when used as anything but a tool to solve specific,
discrete, communications issues is really problematic_

This one generated the most discussion. I would say sort of, but you went too
far.

Any set of poorly understood principles, dogmatically applied, is going to
work out badly. Agile is actually a set of good principles that addressed a
major problem in the common wisdom back in the day. But the pendulum has swung
and it is often applied poorly.

That said, there are other problems in organizations which are prone to,
"poorly understood principles, dogmatically applied"...

------
crispytx
Yes

------
brilliantcode
1997: I created my first website on Netscape Navigator. I was 10.

2007: I created a textbook trading RoR web app. I was 20.

2017: I'm struggling to create my first front-end website on Chrome and I
haven't decided on the back-end. I'm 30.

The barrier to entry is indeed very high and no signs of slowing. I blame the
explosion of low-interest capital from VC's fueling this fracturing.

~~~
brwr
Building a website doesn't have to be complicated. You build a Rails site 10
years ago. You probably used jQuery, if you used JavaScript at all. Why can't
you do the same today?

The real problem here is that not enough developers understand that "just
because you can, doesn't mean you should." Once more of us get a handle on
that, life will be better.

~~~
brilliantcode
> You build a Rails site 10 years ago. You probably used jQuery, if you used
> JavaScript at all. Why can't you do the same today?

You can and I do. However, I am thinking of using polymer or vue.js as I think
they are a much lighter candidate than react.js & angular.

The power of marketing is underrated in the developer circles.

~~~
brwr
If you still use Rails and jQuery, why both with Polymer or Vue? What is the
benefit they give you?

Promise I'm not giving you a hard time. I'm honestly curious if there's
something I'm overlooking.

~~~
brilliantcode
I asked the same question last year and to be honest, building a SPA is tough
with just jQuery. It's more of my needs changing, I don't think SPA can be
ignored in 2017, the progressive web app and AMP will put a huge dent in the
native apps space.

I just like to think that I'm developing a mobile app with front-end
javascript framework....it's just the tooling and prerequisite knowledge is
quite chaotic. Finding the right articles (up to date) is half the battle, as
it's scattered in endless git repo pages.

~~~
codingdave
I'm not sure why an SPA with jQuery is tough. $.ajax. Send data. Do stuff in a
back-end. Return data. Update divs. If it is tough, you might be trying too
hard. I'm not trying to be glib... it just sounds like you might be buying
into the over-complexity that the original question was talking about.

~~~
flukus
The problem with jquery is that the state is stored in html elements. It makes
it hard to debug, maintain and learn bigger applications. Things like
accessing a hidden variable become DOM traversals rather than property
accessors.

~~~
codingdave
jQuery is just a framework, if even that. If you choose to use it to store
state in html elements, that is your choice. And yes, a common one. But the
framework does not force it. If you make an AJAX call in jQuery, you get JSON
back. (Or, I use it to get JSON back... you can send whatever you want back.)
You can do whatever you want with that JSON.

Frequently, I do store metadata in a DOM element because the next event I will
react to is a click on that DOM element, so I already have a handle on it from
the ui element jQuery gives me... I do not have to traverse the DOM. But if
the future use of the data is NOT going to be a response to a click on a
specific DOM element, then no, I will do something else with the data.

Again, just because everyone else does it doesn't mean you have to, and
doesn't mean it is inherent in the tools. I'm not saying jQuery is the best
tool out there... I'm saying that complexity in an SPA doesn't come from
jQuery itself, but from design choices made with it.

~~~
flukus
True, it would be better to say that it's not great to build an SPA with just
jquery. It compliments a number of other frameworks that are good for SPA's.

------
justinlaster
1\. I think this is rather obvious, work with what you have. Maybe think about
hiring specifically for areas your team is in lacking in, as long as the team
as a whole will see decent benefit from it.

2\. I hate to say you're doing microservices "wrong" but I'd really question
project structure and practices being the culprit behind the cost of doing
devops with microservices.

3\. This seems like an engineering fault, rather than some implicit principle
behind those concepts causing more downtime.

4\. How is CI a plaster on the problem of microservices? CI is useful with or
without microservices.

5\. Agile was always meant to be a _guideline_ , not an end all and be all.
It's meant to get your team to figure out how it wants to work, and write code
before process. See: [http://agilemanifesto.org/](http://agilemanifesto.org/)

The problems you are describing seem like big problems with your team,
engineering and management. No amount of process and technology is ever going
to fix a dysfunctional (sorry if that's too blunt) team. What I get from this,
instead of having processes in place that make it easy to move code out,
you're removing tooling to slow things down intentionally with the superficial
result of "stabilizing" the entire development effort. The solution appears to
be to get your team to write less code, and force management to bow down to
the new reality of these "stabilizing" changes. Both of which can and
sometimes should be done regardless of processes and tooling in place.

The best code is the code you don't write. But don't blame the tooling on
making it easy for a team to be lazy and remove the all important
characteristic of a team self-critiquing (i.e, "Do we really need this
feature", "That'd be nice to have but right now we're managing to get things
done.", "Did I actually test my code, was it reviewed, or am I just counting
on the fact that I can shove something else out later while our redundancy
systems pick up the slack?")

~~~
mhluongo
Quite a few of these issues are common in other orgs. "You're doing it wrong"
isn't great advice :/

~~~
justinlaster
I would say in a lot of cases understanding that there are some basic failures
is probably a great starting point to cleaning up the development effort.
There's not much else I can say other than that, considering how vague OP's
post is.

"Good" engineers will get things done and use common tooling to their
advantage. This requires actually understanding the principle behind the
tools, not just shoving things in and hoping it all magically works.

If you have a lot of "good" practices that are supposed to make it easy to
move code around and you find that things just keep breaking, one could
reasonably assume that it's simply highlighting an underlying issue. I'd start
figuring out which engineers (and management) is causing more work for our
organization than they're putting out.

What I think we're seeing from OP is lot of "in name only" practices.

~~~
mhluongo
Some good practices aren't a good fit for a particular organization. Moving
the discussion to whether your engineers are "good", rather than whether they
understand the organization's needs, is reductive.

If you want to develop better practices in an industry, saying the
practitioner should be "good" isn't very helpful. Of course they should be
good! But unfortunately, despite the trope, we can't all hire the best, and
part of the reason we have best practices is to work well without only hiring
the top 1% of engineers.

An example from my experience (mentioned in another comment)- microservices
are a good practice in many larger orgs, because a big piece of what they
solve is political- but the overhead of running a distributed system at a
small org often isn't worth it.

~~~
justinlaster
I put "good" in quotes for a reason. I never said "hire the best"; that isn't
a requirement for anything that was stated.

There shouldn't really be a measurable overhead of running a distributed
system, at least in the context of microservices. I strongly disagree with the
sentiment that a distributed system isn't "worth it" at smaller organizations.
I'm part of one, and it helps keep things flexible while increasing
reliability of the "overall" system(s).

But that's neither here nor there. One shoe size won't fit everyone, but OP
ran down a gambit of things and seemed to have issue with each one. It is
exceedingly unlikely they are doing anything eccentric enough to the point of
proclaiming CI is just a bandaid on the broken concept of microservices. I
will contend that the source of OP's insights are... misappointed, and by
breaking down efficiencies and flexibility they're merely masking certain
underlying problems.

What's more probable? An organization hired some wrong people, or a generic
list of strongly supported practices over the course of two to three decades
are to blame for an organization's failings? I guess that's my take on it.

------
EdHominem
No, but your rules don't resonate with me even though I feel the same overall.

1) Not the best language, but not the worst either. There's no excuse except
microcontrollers for C these days (even though I still like it) and the fairly
decent JVM can't excuse Java. I think people can come up to speed in a new
language pretty easily. It's paradigms that are hard to learn, not syntax.

2) Sounds like you don't have devops. That's a solve-it-once sort of problem.
And you have to solve it soon enough for some pieces so it shouldn't be put
off. You need to be good at it.

3) It certainly can. It is increasing the size of your system considerably -
not just the original system, but also the debugging rules for that system
plus (as noted) the debugging rules for the debugging rules ad-infinitum. But
what do you propose as a solution? Perfectly trained humans on-call? A
procedures manual as detailed as the hypothetical code?

4) Well, lack of CI seems insane regardless of what sort of architecture you
have. It's a symptom of not understanding the tools.

5) Capitalized anything is always bunk. But if I hear agile as meaning "short-
term goals inside long-term goals, and continuous re-evaluation" then it makes
perfect sense and has helped as a consultant and in industry.

------
GFK_of_xmaspast
I don't do anything approaching microservices but a good CI setup combined
with a good test suite is an absolute blessing that verges on a 'must have'.

------
kmicklas
> 1) Choose languages that developers are familiar with, not the best tool for
> the job

This is probably true but also the root cause I think. Enough developers
aren't familiar with the right tools and abstractions (modularity,
abstraction, purity, reproducability, etc.) that we just keep rehashing the
same bad ideas in a never ending stream of new languages and frameworks that
push the same decades old ideas.

------
draw_down
Ultimately, though complexity is a real thing, the word is mostly used to mean
"what I personally don't like".

------
diminoten
Just to add to this a bit, what do you all think of the idea that "code is a
code smell"?

In other words, if you're writing code, make sure you actually need to write
it, and can't otherwise find someone else who's written/released/maintains it.

------
hmans
Yes, we are; no, it's not just you. Next question.

------
bbcbasic
Horses for courses.