Tiny Houses and When To Throw Away Code

Original Post

Sometimes... Well, to be honest often times, we have to get outside of our comfort zones if we hope to grow as individuals.  The problem with "growing" is that most of us think of personal growth too literally.  We see a guy in a suit and tie, driving his freshly waxed car, and we have no idea that he is screaming inside because he's up to his neck in debt.  We see a family of 5 and can only imagine the struggles they must be going through, and gloss over the smiles on their faces because they are rich in love.  We measure our growth by scales of not only what we've learned but how much we've acquired.

In many respects the concept of a Tiny House is a direct rejection of the classic definition of growth.  Rather than growing rich in possessions tiny house pioneers are growing rich in experiences.  It is still dominated by an overwhelming number of younger Millennials, with Boomers and Gen X'ers still choosing the traditional Mc'Mansion, so it's hard to say what that life will look like in 30 or 40 years.  Still, the concept of having less to do more is something that I can appreciate.  This isn't a idea that is exclusive to lifestyle, and it shouldn't be, because software engineering is a good example of the kind of house you build when there is no ceiling, and no walls to hold you in.

Software is not as rigid as building a home.  If you need more resources you just take them.  This isn't always true in a console or handheld space, but you can move the resource walls more easily than moving around a physical space.  Does feature A need another megabyte?  Okay it looks like feature B and C are getting trimmed.  Again, this is all fine and well for consoles but there is a very stark difference in attitude when your focus shifts to an expandable architecture like PC.  If feature A needs another megabyte, you just take it.  There are no borders, no constraints; nothing outside of insanity is off the table.  As a result, software engineering on PC is very much a problem of "filling the space you have", but "space" has a vague and loose definition.

At the core of the tiny house movement is a simple recurring mantra; If you have space, you'll find a way to fill it.  If you live in 300 sqft or 3,000 sqft, in time you'll find the walls closing in around you.  The more space you have the more things you'll have that serve only 1 purpose, if any.  You'll have rooms that you haven't visited in weeks, filled with nick knacks that you haven't picked up in months, and scraps of distant heirlooms and memorabilia that you haven't seen in years or decades.  Code is not too different, other than the fact that we don't measure our walls in square feet, we measure in gigabytes and terabytes, and every day that technology advances our walls get a little bigger.

A consistent issue with software today is a direct result of an ever-expanding space and a drive to increase productivity.  To enhance productivity we integrate third-party software.  Because of time constraints, the software chosen is usually whatever the person tasked with the job is most comfortable with.  After integration, that engineer has now become a point of failure.  Since many modern projects are boiling down to the assimilation of many other projects in the interest of productivity you can extrapolate this to an entire master project.  Suddenly we have a beast of a project; a twisted abomination of architecture that looks perfectly normal on the outside, but on the inside it is barely holding itself together.  The project may take hours to check out of a code repository, hours to configure and compile, and many more hours to install servers and ancillary packages and software services needed to test the application.  No one in the company has a complete grasp of exactly how any of it works, but it works somehow.  Suddenly, we are staring at 10+ gigabytes of repository content that compiles to a few hundred megabytes at most and requires a small platoon of services running on the release machine to launch the application.

In the confines of a tiny house we accept a certain amount of discomfort.  We compromise by asking ourselves; Do we need 3 types of coffee makers?  How many sauce pans does a couple need, how many shoes does one person need?  In a tiny house we accept that our cutting-board is also a dining table, or that the couch is also a bed.  Anything that displays less than 2 functions is wasteful and excessive, and anything that hasn't been touched in the span of 1 year should be discarded or gifted to someone who needs it more.  It's not hard to see that life wouldn't exactly be easier by living a minimalist life, but it would be manageable when everything you need is in arms' reach.  Everything has it's place, and you don't spend 8 hours looking for the hammer to hang a picture, then eventually get fed up and buy a new hammer instead.

As engineers, we've all been there when the deadline clock is ticking and you've spent a frustrating day searching and asking for help and no one can find the feature that exists somewhere in the depths of the code, or they don't know how to use it.  We've all been there; when we finally find what we need and our head starts to spin as we follow the graph of dependencies required to use that feature.  We've all been there; at 2am, when you've thrown your hands up and realized that you probably could have developed a solution that was smaller and required a fraction of the libraries and classes of it's predecessor, and done it in the time it took you to find the existing system.  We've all been there, and it's not an easy pill to swallow.  Though some of this is inescapable as code bases grow with genuinely new features, there is the inevitable fat that never seems to get trimmed from projects that live on, long past their time.

Is bigger always better?  Do we need the 3,000 square foot Mc'Mansion of code bases?  Why does it take several gigabytes of source content to develop less than 1/100th of that content in the final release?  How many rooms have been collecting dust, how many heirlooms are we inheriting because, "you never know"?  Are software engineers true believers in re-use and recycling of code, or are we just a bunch of closet pack-rats living in a house that keeps getting bigger?

@Ben_Quintero