Software Craftsmanship: What it's all about.
cleancoder.posterous.com
cleancoder.posterous.com
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.
This only becomes a problem for weak developers that lack one of the most important skills: the ability to say "no".
Don't know why this is on the front page.
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>
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.
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.
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.
I often advocate functional and integration tests over unit tests for this very reason. A good functional test is testing use cases, which is exactly what the customer wants! Unit tests exist primarily to improve code quality and aren't very useful for anything else.
Larger companies, especially non-technology ones, unfortunately just want cheap, quick software churned out (in my experience).
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?
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.
Those that don't adapt to this, die (or run out of money, which feels like dying).
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.