4 ms·

Software Craftsmanship: What it's all about.

46 points by koevet 15y ago

jayfuerstenberg 15y ago
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 15y ago
  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?
nubela 15y ago
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 15y ago
  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 15y ago
    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".
RyanMcGreal 15y ago
That website needs some design craftsmanship. I needed to Ctrl-a just to read the text.
- icebraining 15y ago
  Agreed. Readability version: http://www.readability.com/articles/vbcgecjs http://www.readability.com/articles/vbcgecjs
- jamesbritt 15y ago
  There are assorted "zap" bookmarklets that can be a real eye-saver when needed. https://www.squarefree.com/bookmarklets/zap.html https://www.squarefree.com/bookmarklets/zap.html
spaznode 15y ago
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.
DanielBMarkham 15y ago
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>
- 15y ago
Produce 15y ago
The obvious solution is to stop taking crap jobs. There are places which do things well, though, admittedly, they are in the minority.
JoeAltmaier 15y ago
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).
MrKurtHaeusler 15y ago
Anyone interested in what its really all about should read the book: http://www.amazon.com/Software-Craftsmanship-Imperative-Pete-McBreen/dp/0201733862 http://www.amazon.com/Software-Craftsmanship-Imperative-Pete... 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.
skatenerd 15y ago
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.

46 points by koevet 15y ago

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 15y ago
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?

nubela 15y ago

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 15y ago
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 15y ago
  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".

RyanMcGreal 15y ago

That website needs some design craftsmanship. I needed to Ctrl-a just to read the text.

icebraining 15y ago
Agreed. Readability version: http://www.readability.com/articles/vbcgecjs http://www.readability.com/articles/vbcgecjs
jamesbritt 15y ago
There are assorted "zap" bookmarklets that can be a real eye-saver when needed. https://www.squarefree.com/bookmarklets/zap.html https://www.squarefree.com/bookmarklets/zap.html

spaznode 15y ago

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.

DanielBMarkham 15y ago

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>

15y ago

Produce 15y ago

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

JoeAltmaier 15y ago

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).

MrKurtHaeusler 15y ago

Anyone interested in what its really all about should read the book: http://www.amazon.com/Software-Craftsmanship-Imperative-Pete-McBreen/dp/0201733862 http://www.amazon.com/Software-Craftsmanship-Imperative-Pete... 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.

skatenerd 15y ago

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.