
Gut Driven Development - nevatiaritika
http://kevinmahoney.co.uk/articles/gut-driven-development/
======
empath75
I've been on a team that was absolutely paralyzed by over analyzing every
choice to death. We spent months arguing about chef va ansible, for example.
Sometimes you have to just say: 'Fuck it, we're using chef' (or go, or aws)
because the time you waste spinning wheels is more expensive than the loss of
efficiency from making the less than ideal choice. And those are the times
when gut instincts matter.

~~~
donw
If the team can't hammer things out in a timeboxed meeting, there are some
options.

With new technology, I'll have a pair of team members spend some time doing
exploratory work. Spend some time with the top 2-3 technologies and see which
is the best fit.

Taking notes through this process is important. If we're comparing databases,
include benchmarks and tooling observations. For small organizations, this is
usually a multi-day process. For large organizations, maybe up to a month. But
at the end, the team can make a decision based on at least some experience and
information.

If, on the other hand, we have competing factions that each has experience
with a specific bit of kit, but can not come to an agreement: we roll for
initiative.

Literally.

I have a set of dice in my backpack for this exact situation.

Often, the worst decision is no decision at all, and I would rather that the
team go down the wrong road for a month (and learn from the process) then
spend that month arguing over what color to paint the hangar de vélos.

~~~
amorphid
I'm taking my dice to work from now on.

~~~
dkersten
I have used Siri to flip coins and roll die in work. Often it's prompted
people to make a call (rather than using what the dice/coin said), which is a
great outcome.

------
startupdiscuss
The writer discusses the prevalence of "gut feeling" in development, and how
justifications are often retro-fitted to justify preferences which might be
driven by familiarity, or novelty.

Let me say this in defense of gut feelings:

Sometimes the opposite of gut feeling is process. Bezos recently talked about
the potential pitfalls of process, and Jobs famously warned us against
confusing process with what he calls "content."

The issue is that if you have a process, you end up relying on it to make
things good. It cannot. If someone were to walk into the process and say "This
is just wrong. Come on, do it _this_ way," you could (rightly) accuse them of
relying on gut feeling.

All of this is to say that there are gut feelings and then there are gut
feelings, and it is important to tell them apart.

~~~
rocqua
It felt to me like the argument was that gut-feeling stuff can impede
collaboration. I'd argue that, in large collaborative settings, this is
precisely where process is needed.

This contrasts against safety process, where you add process to defend against
mistakes as opposed to enabling collaboration.

~~~
noobiemcfoob
You have a point. A company's "process" to me has always represented the
message passing system in a multicore processor. The process is the method by
which each core is updated with pertinent information (consumables or just new
rules for their task). Bad process looks like a lot of overhead where everyone
spends more time "communicating" than working.

Ultimately, as long as you can quickly and effectively communicate the impact
of a gut feeling, there is no problem, but they would seem especially hard to
translate into a more formalized process for communicating thought out
decisions.

------
MichaelAza
I'll note that from my experience as a programmer and a manager the best
coders (and best code) was done by the people who "just felt this is the right
way". Usually the code produced is exactly good enough for the task at hand,
and by creating a code base that can be easily refactored (for example, with
lots of automated tests) it can be easily changed later. I always tell my
junior programmers who tend to ask a lot of questions and get stuck up on
process - code whatever you feel like coding. I trust your judgment. I'll
correct you during CR if needed.

~~~
BeetleB
>I'll note that from my experience as a programmer and a manager the best
coders (and best code) was done by the people who "just felt this is the right
way".

I'll note that from my experience as a programmer, the worst code was done by
people who "just felt this is the right way".

Note that I'm not disagreeing with you. This is a classic case of confirmation
bias. Looking at what is common amongst great coders/code is the first step.
But that step is incomplete unless you _test_ against crappy code. Is that
feature you found in great code often present in crappy code? Then it likely
has little to do with code quality...

Coding from the gut is the thing to do if you're a great coder. Not the other
way round.

~~~
coldtea
> _I 'll note that from my experience as a programmer, the worst code was done
> by people who "just felt this is the right way"._

No, the worst code is by people who just wrote it that way because they didn't
know better, and who don't have any strong opinions one way or another.

------
jkmcf
I practice Dirk Gently Driven Development.

Basically, I more or less know what I want to do, my fingers wander, encounter
things I didn't anticipate and I modify my work. When it is done, I refactor
and add tests where necessary.

Not the best methodology, but that's how my brain works -- all situational
recall.

------
frozenmangos
_The Psychology of Human Misjudgment_ by Charles T. Munger is the single best
thing I've read on this topic: [http://www.hb.org/the-psychology-of-human-
misjudgment-by-cha...](http://www.hb.org/the-psychology-of-human-misjudgment-
by-charles-t-munger/)

I think it's unique to tech that people are biased toward thinking things are
good just because they're new. I've found that in most of the rest of the
world, people think new things are dangerous, frightening, insubordinate,
disruptive, and irritating.

~~~
kpmah
Forgive me for getting political, but I think Trump was a good non-tech
example of 'good because it's new'. Without a voting record and few concrete
policies people were free to project their hopes on to him.

I have also noticed the 'dangerous/frightening because it's new' bias. I don't
understand why it flips one way or the other. People are weird! :)

~~~
LyndsySimon
This seems very apt to me.

I voted for Trump, and found my justification after I had decided that I would
probably do so. The bottom line was that I wasn't going to vote for Clinton
and Trump was the only other viable option.

I've also chosen relatively untested libraries for projects because I'd
already used the more mature choice for another project and hated it :)

------
ImTalking
This is why I can't understand age discrimination. We oldies have a wealth of
experience which we can turn to. How can a new programmer have a "gut feel"
which should be listened-to when there is little to no experience? The oldies
"gut feel" is real because it is based on true experiences; either direct
experiences or experiences of (say) a colleague.

And most of the experiences that I have, for example, are largely independent
of a particular language or environment, they are more about the correct way
to structure 'things' within programming regardless if it's GO or COBOL.

~~~
LyndsySimon
For reference: I'm 32.

It seems to me that developers go one of two ways as they gain experience -
they either become set in their preferences and ideas and become resistant to
change, or they consciously suppress that instinct and realize their
preconceptions may be incomplete.

I try to be the second type.

For example: I have been writing HTML/CSS/JS for around fifteen years, and
have established a strong pattern for separating structure (HTML),
presentation (CSS), and behavior (JS). There are obviously instances where
these barriers are crossed but those should be the exception rather than the
rule. When I first picked up React, I was appalled by the mixture of the
three. Using inline CSS is a _huge_ code smell to me, yet that seems to be the
convention in React.

The other developers out there who created React and who use it idiomatically
are not morons. Instead of trying to make React fit the way I want to do
things, I set aside my "gut feeling" and follow the convention. I already know
plenty about the type of debt that can be incurred by using inline CSS, so I
watch for that to begin to accrue. If I start to run into those issues I can
raise the alarm and refactor before it gets to the point where doing so would
be a prohibitively complex undertaking.

My point is, you can find a lot of value in that gut feeling without allowing
it to control you.

I'll even go so far as to say that my "gut feeling" is one of my greatest
assets. If code smells to me and it costs very little to satisfy that sense, I
refactor it. I don't have the space in my working memory to remember all the
rules and guidelines I've developed over time much less the reasons for each
of those.

Now, if I'm doing a code review, that's another story. Then I'll note that
something has a smell, describe how I identified that smell, and describe my
justification for it. I see code review as an opportunity to transfer that
knowledge.

------
sbov
Gut Driven Development is oftentimes confused with First Solution Encountered
Driven Development or Familiarity Driven Development. Depending upon the
circumstances, none of them are necessarily bad.

------
Jtsummers

      In my experience, you can almost always examine your opinions
      and find some objective advantage. If you can’t, your opinion
      probably isn’t very solid. Recognising your gut feelings and
      examining them can be eye opening, and can make you a better
      developer.
    

This sort of introspection is useful for more than just developers.

    
    
      Once you recognise biases like this it will become clear to
      you that people often start with a biased opinion and then
      reason backwards from there to support it. You’ll do it too,
      and it’s OK to do that as long as you can examine it and put
      forward a solid argument. Never think biases don’t apply to
      you.
    

To help counteract this, you have to put yourself in the position of
questioning your views/feelings/beliefs, and putting them in the context of
the opposing views. If you think X is right, find those that think ¬X, or a
variant of X, and consider why they believe it. Genuinely questioning and not
just seeking out confirmation to your positions, or counterarguments to
theirs. Usually the correct views are somewhere in between, or will be
revealed to be subjective (that is, no right or wrong, either irrelevant
because it's unprovable or a matter of tradeoffs and what's considered more
important by the different parties).

------
jaequery
One thing I learned working with many developers over the years it's that this
is fairly dependent on the individual.

Some absolutely thrives in an environment without process, I've seen some who
simply crushes it without processes and procedures. Beneficial for early
stages of company who wants to get a product out asap.

And there are those who thrives with processes, useful and even critical for
later stage of the company. I think it's important to have a good balance of
these types of developers to maximize each of their strength and weaknesses.

~~~
samiru
I think it has something to do with different kind of processing in the
left/right hemispheres of the brain. For most people left brain type of
thinking (attention to detail, focus on process) dominates, it also may be
harder for them to see where and how the "gut feeling" originates.

------
ratliffchrisb
I think the last paragraph in the article is key, the most interesting and
tiring arguments are the ones where both parties believe the other is arguing
from the gut and have retroactively reasoned while they are being perfectly
rational. Being able to see when you might be doing this as well often makes
the discussion much less adversarial.

