
Professional Corner-Cutting - rfreytag
http://blog.ometer.com/2016/05/04/professional-corner-cutting/
======
rossng
While I understand the point being made here, it is worth remembering that
cabinets are not continuously modified by large teams for years on end.

Corner-cutting generally makes things harder to maintain, which has a severe
knock-on effect in software, less so for furniture. As a result, I think there
are often fewer corners that can be safely cut in software. So, in many
scenarios, this advice essentially boils down to the somewhat self-evident
'don't do completely pointless things'.

~~~
fisherjeff
Cabinets might not be continuously modified for years, but the house as a
whole will be. The backs of the cabinets will continue to matter much less
than the fronts, both for aesthetics and maintainability.

On the other hand, somebody's definitely going to regret that hacky thing you
did inside the wall when you remodeled the kitchen and knew it was a bad idea
at the time but did it anyway.

Admittedly, though, I may just be too emotionally invested in this analogy
thanks to my house's previous owner's infuriating obsession with construction
adhesive.

~~~
Loughla
The people who invented construction adhesive, expanding foam sealant, and
that stupid rubber-in-a-can sealer need to all be drug out into the street and
shot.

~~~
Bartweiss
That foam sealant is a crime against construction. It's always hideous, and
usually far more long term trouble than a proper solution would be.

------
13of40
OK, I'll start: When I write code, I spend a fair amount of time on making
sure it's readable (e.g. StyleCop compliant on the first pass, well-commented,
human friendly abstractions) and it's not for aesthetics. It's so the next
poor bastard who has to change it doesn't have to stay up all night inferring
my intentions from a bunch of one-letter variables. There's usually no "back
of the cabinet" where I can safely cut corners.

Relevant: [http://media.gettyimages.com/photos/cooking-oil-
containers-a...](http://media.gettyimages.com/photos/cooking-oil-containers-
are-seen-inside-the-construction-of-a-on-6-picture-id508865304)

~~~
skybrian
The place to cut might be somewhere else (like leaving out unnecessary
features or abstractions).

The original post is just giving us a metaphor - you need to decide how it
applies.

~~~
mnsc
"unnecessary ... abstractions"

This is what I thought of when the artice said "visible toolmarks". An
abstraction layer missing/not fully implementer exposing "ugly" plumbing code.

------
santoshalper
You're going cut corners either way, either because you made intelligent
choices where to cut corners, or because you ended up being forced to do a
shitty job on whatever you were working on when time/money runs out.

There is almost never enough time or money to do every single thing perfectly.

~~~
ben_jones
Here's an alternative: don't make time a factor while you build a foundation,
then, when time does become a factor, simply extend the foundation as far and
as rickety as necessary knowing at the very least you have a rock solid
foundation.

Practical example:

You're building a CRUD app. Start by implementing robust logging, monitoring,
testing, containerization (if prudent), and a proven framework-environment,
then create all your endpoints and your client application.

When your app inevitably fails the logging, monitoring, testing, etc, will be
a nice consolation prize.

~~~
makmanalp
The counterpoint here is that it's oftentimes hard or impossible to know what
exactly you'll eventually be building before you build it, especially with
something like a startup where experimentation until you get product-market
fit is the norm, or a project which has an expected life of multiple
years/decade(s).

If you sit there pre-planning every last detail of something, that usually
means you end up making a lot of assumptions that eventually turn out to be
false. It can be a sad day if one day realize you that your entire code is
structured towards doing stuff one way, and then your requirements are the
opposite. This is true even when you think you've thought of every possible
option - life has a way of being surprising.

Specifically abstraction is a tool to be used strategically, not a blunt
instrument to bash your code with. Rushing into abstraction can kill a good
codebase because it's difficult to refactor code to extricate yourself from a
bad abstraction. Also a lot of abstractions come at a cost, e.g. the build
takes longer, there is more boilerplate to get a simple thing done, you need
multiple servers and orchestration to run the app, etc etc

I'm finding that the thing to do instead is to build things open to change and
extension, but initially allow some inefficiency / repetition / stupidity in
favor of less complexity. You build in complexity as you need it. Examples:
Don't start with the fanciest logging stuff, do use a uniform function call
that is easy to find / replace later on. Don't start with containers or even
separate repositories, but do keep logic between areas of code cleanly
separated such that you can pull them apart easily later, etc.

------
groundCode
Some food for thought there.

This I quite liked - probably because I've seen it happen a few times:

> We should not ask customers for more precision than they can give us (a
> symptom of this is to badger customers or managers for detailed
> “requirements,” then complain endlessly about “changing requirements”).

I think the idea of context is vital really. If you are a hired gun building
something you aren't personally going to use, then you do need to be able to
put yourself in the customer/user's shoes. Ideally, you should get to know the
subject area well enough to be your own customer so you can bridge the gap
between what the customer says they want and what they actually need but just
haven't expressed yet.

------
makecheck
It is hard to accurately compare software to any other craft because changes
are requested practically forever. (Nobody asks a woodworker to go back and
add a 4th drawer to a dresser that was built 6 months ago.)

I find that highly-granular revision control systems go a long way toward
avoiding cruft and they remove the temptation to cut corners. When you are
halfway through a huge change and you encounter something that is causing
problems, carve out the problem into a _separate_ commit and _fix it_!
Similarly, if something that was expected to be a simple feature turned out to
require general architectural changes, carve out the general changes and
commit them _first_.

