We are different than the Tech Giants. We can and should develop software differently from them. Generally, we have simpler needs.



## A Part of the Tech Giant Discussion

Lately, there is a wider discussion in the public sphere about some of the ills that come from the emergences of very large tech giants (companies) that control or influence large aspects of our lives and society. Those are interesting, and I believe worthwhile, discussions. This article is but a sliver of that larger discussion.

How does the existence of these tech giants affect our software development practices? In one way, they encourage the creation of complex software solutions.

## A Different Class of Problems

These exist: super-large companies that serve super-large swaths of the population with super-expansive products. They employ some of the smartest and brightest and most innovative among us (to optimize an ad, a Like or a Buy button, among other things). 

But these are not you or me (statistically-speaking).

This is a different class of problem. 

I am a super small company, serving a minimally-viable audience with products that yesterday were toys.

## Different Problems, Different Answers

Do I need 99.999% up-time? Do I need to auto-scale? Do I need redundancy?

Do I need to A/B test? Do I need to optimize my mobile experience?

Do I need to be AAA accessible? Do I need a CDN? 

Do I need to follow that convention? Do I need the lint rules?

Do I need CI? Do I need to upgrade? Do I need a certain architecture?

Do I need to use that protocol? Do I need to follow that framework pattern?

Do I need that project layout? Do I need to split up this code?

Do I need monitoring? Do I need persistent logs? Do I need backup?

Do I need to depend on that library? Do I need to cover that case?

## Solutions Mis-matched

The answers to those questions aren't definite. It's a giant "it depends". We say this and joke about it. Then why do we sometimes fail to act like it?

The gravity of the Tech Giants are large and difficult to escape from within software development. They have great talent. They write great think-pieces. They prove their need in great white papers. They (and their influence) are prolific on the speaking circuit. They invent and push the state of the art for their class of problem. It's all very exciting. 

In some ways they've surpassed us. (In so many things!) Why not in software development as well?

We software developers and architects and operations engineers try to keep up. We use the latest, greatest. We want to be on the cutting edge. We don't want to look inferior or be inferior. We want to be marketable. We want to attract some of the best and brightest.

But we *will be* more bright if we see these as often different classes of problems. We will stop resume-driven development. We will learn best-in-class tools and apply them to our best-in-class problems. 

## Avoid the Cost

It's fun to punch above your weight, but it takes a lot of effort. Yes, you might be prepping your team and product to be the next rocket ship. Good luck to you.

But if you're happy to play within a certain scale and class of problem, you might want to avoid some of the costs of those more expansive problems.

Save money. Save time. Save the need to get more help. Save the need for some of those conferences tempting you to a new tech. Save your breath trying to keep up.

What do you think? Are there different classes of problems? Do we attempt to develop software in the mode of the tech giants when we could otherwise happily avoid it?

## Example

Edit: I've added this example because it really speaks to the same idea.

[A company not using Docker](https://launchyourapp.meezeeworkouts.com/2021/03/why-we-dont-use-docker-we-dont-need-it.html?m=1) - They feel some pressure to use it. They don't see the need. They see it as meta work getting in the way of the real work they need to do.

Allow keyboard users to horizontally scroll code blocks

We Want to Develop Software Like the Tech Giants

The pace of technology change requires nimble solution change.  Small solutions help.



## All-in-one is Expensive

How many times do you setup a project?  Once.  But how many times does tech change over the lifetime of your project?  Many, many times.  

There is an allure to all-in-one solutions: everything has been preconceived; it's all bundled in the box together; it just works.  Once you pay the price of learning the whole package, they say, you'll have a complete toolkit to solve your problems.  But this upfront cost is hardly the final price to pay.

Moving away from an all-in-one solution is even more expensive than choosing it in the first place.  Because it came as a package, it often has to leave as a package.

## One-upping Technology

There is so much movement in so many technology spaces.  Subjects are ever-deepening.  There are many players in these spaces, developing new techs every day.  Each new tech seems to leap frog the previous and expand into new, interesting territory.

When something comes out that is compelling enough to make us want to use it, we'd love to add it to our development arsenal.  We can keep with important trends individually, not waiting for a convenient all-in-one's to appear.

## Pieced-together Solutions

If we have pieced our own favorite techs together into a solution that works for us, we're more ready to swap something out when the new, compelling tech comes along.  We don't have to throw away the rest.  We can use them together.

Each of these small solutions can do one thing well.  They can have well-defined single responsibilities that can be learned, optimized, debugged, or swapped out easily.  This means as things change, we can advance our own solutions faster, approaching the pace of the source technology change.

If we are more nimble in advancing our solutions, we can improve more quickly.  We can give more joy to our customers.  We can give more joy to the developers.  The a la carte approach to our solution choices enables us to pick up and put down solutions as they become available.

Have you experienced this before?  What small solutions have you found easy to move away from or advance into?

The pace of technology change requires nimble solution change.  Small solutions help.