Code And Cocktails

@nashjain at @boston_sc - Clean Code vs. Sufficient Design

| Comments

I kept wanting to say something to the effect: "But no... you gotta make
the code clean..." (and I probably pretty much DID say that several

But the point Naresh[2] made is valid: Spending lots of time on making sure
your code is clean may not be the best/most profitable way to spend your

I think a good way to summarize his point is: "If you have a good team
(which you trust), with smart people and tight collaboration with
customers, then the code is not important and will take care if itself".
He suggests an approach of building apps/features quickly (and perhaps
not entirely cleanly) so that you can get feedback from customers
quickly to determine if it is worth spending more time on it. This
makes sense - and if the app/feature is worth it you go back and make it
better. But if it is not worth it - you don't bother; it would be a
waste of time/money.

The important issue here is what 'good enough' means. Naresh says that
you make this app/feature 'good enough'. He gives two different
examples: 1) a feature that they put together quickly and the
customer didn't care about so nothing more was done and 2) an app which
is being slowly and carefully crafted because the initial release needs
to be awesome. Both are "good enough" but "good enough" is very
different in each case.

If the team doesn't agree on what "good enough" means then you have
problem there. Which brings up that this idea that the code will take
care of itself seems to be predicated on the fact you have a great team
with high customer collaboration.

So what if you don't?

Naresh answered this by asking if pushing strict TDD or Clean Code (TM)
was a good way to fix that situation. I can't say it is[3]. Education
seems to be the best thing.

Educating my coworkers is something I realize I need to do - but I am
not sure how to go about doing it. We don't pair program - so I can't
directly "show". I need to find a way to do this.



[1] I feel that my disagreements with Naresh's points are not entirely
logical and are based around my current lack of trust (and opinion
mismatch) with my current team. I agree that his approach is pragmatic -
I worry that 'pragmatism' can be the cover for lots of dumb stuff which
cause pain in the end. Again this goes back to a trust in the team - I
do not currently have trust in my current team and that is coloring my
opinion of how I think his suggestions could work. For them to work in
my current situation would involve a large change, not only of myself,
but of the organization and its members - which I don't think is likely
to happen (but is this opinion too just because I do not trust the

[2] @nashjain

[3] Although as Zach[4] pointed out: in my current situation, doing TDD
and making the code Clean(TM) is sort of a defensive strategy for me.

[4] @zdsbs