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-
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.
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".
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.
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.
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.
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.
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.
>But the test is user wants, not code functionality.
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.
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?
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).
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.
