
Software Craftsmanship: What it's all about. - koevet
http://cleancoder.posterous.com/software-craftsmanship-things-wars-commandmen
======
nubela
My previous work experience at a startup I shall not name had a problem with
the above, which really went against my principles as a programmer, knowing
that life is gonna be hard because I will come back to this code again, even
if I ship it out, just in time for the scrum cycle. I hated it, and really
demotivated me. This very reasoning also made me not see Scrum in such a great
light, or perhaps it was the way the startup implemented Scrum. -shrugs-

~~~
inerte
It's not the way this particular startup implemented Scrum. If you're doing
fixed-length iterations, I've seem many times managers/PO asking for some
stories to be done during the next cycle.

Now, some people will say "You're doing it wrong", but here's the deal: Scrum
facilitates this to happen, and you have to spend a lot of time and energy
fighting against it. The boss will come and say "Here's what you have to do in
the next couple weeks". And the velocity becomes a purpose by itself. Instead
of measuring what happened, it's a number to be beaten. It's really sad when
this happen, but I've seen it a lot of times.

~~~
rickmb
But isn't this exactly what the core of craftsmanship is about: aligning
yourself with the needs of the business (i.e.: try to beat that number,
increase velocity, finish more stories), but not compromising quality?

This only becomes a problem for weak developers that lack one of the most
important skills: the ability to say "no".

------
spaznode
I was mildly interested until I discovered that the blog was void of any
useful content other than an attempt at re-defining craftsmanship to mean
whatever TDD mantra the poster believes in.

Don't know why this is on the front page.

------
RyanMcGreal
That website needs some _design craftsmanship_. I needed to Ctrl-a just to
read the text.

~~~
jamesbritt
There are assorted "zap" bookmarklets that can be a real eye-saver when
needed.

<https://www.squarefree.com/bookmarklets/zap.html>

------
DanielBMarkham
Geesh. Uncle Bob again. The man is everywhere.

Here's the thing: "craftsmanship," no matter how many "we are going tos" and
"we are not going tos" you put around it, focuses on the thing instead of the
environment. If I go to a craftsman to build a chair, the reason I select a
craftsman is because I know I can sit on the dang chair after I buy it. It is
this economic trade, my money for a chair I want, that defines the craftsman,
not anything he does to the chair itself.

While Bob means well, there is an economic decision at the heart of many
startups which I can state plainly: don't spend a second doing anything that
people don't want. Not only does that include testing, that includes coding as
well. That's right, startups avoid even writing bad code, much less good or
great code. Every little thing you do has to be tested first -- and the only
test that matters is "do people want this?" Not some kind of unit or mock
test.

It's a totally different situation from corporate or normal small team
programming where you already know somebody is paying you, you're only
supposed to make them happy. Bob gets away with this because his market is
those guys, the guys that are 95% of the market for his books and such. But
since this is HN, I have to point out the differences between those guys and
the average startup team. In the startup world _most of the time you don't
even get paid_. Which means that all these discussions about languages,
testing, craftsmanship, and the rest of it? It's just bullshit for some other
folks. The guys who get a steady paycheck. If 19 times out of 20 the code you
write for a startup will never be seen again, much less maintained, _there is
no maintenance programmer_. There is no project. There is no customer.
"Craftmanship" or "Quality" have no meaning. There may be some guy making
12-legged chairs from jello somewhere in the world, but no matter how great he
is at doing that, and no matter what a wonderful job and hard work he puts
into the product, he's not a craftsman. He's just some guy with mild Aspergers
who is spending too much time with jello.

I think we do a great disservice when we talk about programming as something
that can exist in a vacuum. It does not. Each programming team exists inside a
certain economic reality, and that reality needs to be considered with each
decision that is made. There is no universal standard of craftsmanship for
programming because programming is a form of thinking, and there is no
universal standard for that, either. To defend Uncle Robert, you _can_ make
broad generalizations, and for most business programmers I'm there with him,
but it's important to know where the limits are to these things. Bob has a
tendency to speak in overly broad generalizations.

</rant>

~~~
ekidd
Even in a seed-stage startup, you'll often wind up doing heavy refactoring and
redesign.

Let's say you've just spent two weeks building a prototype billing system, and
you demo it to some potential customers. They get excited, but they ask for
time-tracking features. So you add some. Great! Now, what about your old
features? Do they still work, or did you break them?

In my case, I just tweak 2 or 3 acceptance tests, watch everything go green,
smoke test for 2 minutes, and run 'git push heroku'. Without unit tests, I'd
waste the next hour carefully hand-testing all my features.

Now, this might not fit your personal coding style. That's fine. But tests
actually let me go _faster_ , even on a 3-day project. In a seed-stage
startup, you need to get in as many iterations as possible before you run out
of money.

~~~
DanielBMarkham
Apologies if I did a poor job explaining. Perhaps I should restate. Yes, test
first. But the test is user wants, not code functionality.

So to your example, you sell a mock-up. If they want it, then you go back and
test-first and code. If you can find out they want time tracking without
coding, what are you coding for? If you are coding one thing and they really
want something else, what are you coding for?

I'd argue that if you have customers that are directing your sprints,
timeboxes, or whatever, then _you're already past the point I am talking
about._ They have money, they have needs, they express needs to you and you go
fill them. This is a great spot to be in as a startup! But at that point
you're really just quasi-business programmers, and all Bob says is very
applicable.

The guys I hear who do well always regret that they spend too much time on
stuff that doesn't matter: coding, business plans, reading business books.
Instead they should have just worked out more effective ways to find out what
people want.

If you have a Minimum Viable Product that people want to pay money for, go
code it. And do a good job of it, _because you've already determined that
people are going to pay money for it_. So in that scenario, if you
misunderstood your MVP, then all that TDD is going to be awesome when you
refactor.

There's a third scenario that's being hinted at: you don't know what people
might want, but you think you should code anyway to find out. This is like
building a runway hoping that an airplane will suddenly have an emergency and
need a place to land. I'd argue that you should either avoid this at all
costs, or if you must code, write the cheapest, fastest throwaway crap you
could imagine -- the odds are very, very high that you will never use or see
that code again. If you do? You hit the lottery, and worrying about how badly
you coded something is a ridiculous thing to get uptight about. Every second
you spend creating an artificial world, whether that's a business plan,
program, or sales chart, without validating with the customer is a waste of
energy for an early startup.

~~~
ekidd
We're in violent agreement that startups should write as little code as
humanly possible. I learned that lesson the hard way. You should test your
_ideas_ first.

But sooner or later, you'll get a rough idea of what people need, and you'll
throw together a working prototype. After all, users don't visualize well, but
they're great at extrapolating from things they can see.

That's when I start writing tests, even if it's just a weekend prototype.
Because for me, tests are a net win by the afternoon of day 1. Why should I
spent 3 days writing nasty crap when I could have a decent program in 2?

Now, this won't work for everybody. Maybe it takes a month to prototype your
idea. Maybe it takes you twice as long to do TDD as it does to churn out code.
Maybe your idea is just plain hard to test.

But I'm definitely in complete agreement about customer validation.

------
jayfuerstenberg
Small companies can apply these guidelines/rules effectively.

Larger companies, especially non-technology ones, unfortunately just want
cheap, quick software churned out (in my experience).

~~~
dekz
Some larger companies worry too much about the product and its release date,
and don't seem to care about day to day improvements of software development.

At least from my short experience at a large company, 0% of time is allocated
to improving build infrastructure and tooling. Am I alone in this?

------
MrKurtHaeusler
Anyone interested in what its really all about should read the book:
[http://www.amazon.com/Software-Craftsmanship-Imperative-
Pete...](http://www.amazon.com/Software-Craftsmanship-Imperative-Pete-
McBreen/dp/0201733862)

Uncle Bob seems to have hijacked the term to relabel XP after Scrum got all
the Agile glory.

Or better yet, attend a conference or meetup.

I find the Craftsmanship crowd to be a much better overlap with the HN crowd
than say what the Agile community has become.

------
JoeAltmaier
Writing apps, writing libraries, writing drivers each have a different
threshold for quality. In a startup environment the threshold is under
tremendous pressure, and it can move for good or bad.

Those that don't adapt to this, die (or run out of money, which feels like
dying).

------
skatenerd
in my opinion, the issue is not at its root about being a good craftsman.

what ultimately matters to me is avoiding the painful/frustrating/stressful
productivity crash that can occur when maintaining software.

software craftsmanship is a means to that end.

this is essentially in agreement with what the article said. i think its worth
clarifying that there are things you are trying to _avoid_ , and then certain
practices are means to that end.

------
Produce
The obvious solution is to stop taking crap jobs. There are places which do
things well, though, admittedly, they are in the minority.

