7 ms·

I don't think anyone who is serious about software craftsmanship would dispute the basic idea here ("you should be tasteful and minimalist when choosing depende

I don't think anyone who is serious about software craftsmanship would dispute the basic idea here ("you should be tasteful and minimalist when choosing dependencies"). The problem is that the economics of software development don't really ever require craftsmanship. There are two basic modes of development. 1 - You are a startup, struggling to survive; you have to ship features as fast as possible, with many fewer engineers than you really need to do things right. 2 - You are a huge billion dollar corporation, probably a monopoly, with an enormous moat protecting you from serious competition. Neither situation prizes craftsmanship. The startup just needs to glue together a hack to raise the next founding round or solve the immediate user problem. The gigacorp has more money than it knows what to do with, so they "solve" every software problem by hiring more engineers. There's actually not many companies who exist in the middle ground, where it might be important to produce high quality software. I believe this is also the reason we don't see more uptake of high concept languages like Haskell and Lisp.

intrepidhero 6y ago
This argument can be made in a lot of industries. Farming, furniture making, automotive, consumer electronics, appliances... There are things we can do (and I'd argue we should) systemically to incentivise building for the long term but I think the cultural mindset needs to change first. I hesitate to lay all the blame on consumerism, but it certainly seems like a big part of the problem. I hope that projects like The Long Now and Artemis signal a shift toward thinking more about future generations.
- 6510 6y ago
  The market system is an epic hack, it does fantastic stuff but it is merely a hack. We won't be able to do everything outside its scope. It is a really large scope but not large enough.
- jmchuster 6y ago
  Furniture-making actually seems like something you can draw a lot of intuitive analogies from. You need to make a chair so your client can sit down and work at their desk. While waiting on this chair, your client needs to stand awkwardly at their desk. So they care about how long it takes for you to make this chair, as well as how much it costs and all the normal stuff. You can build a very fancy premium chair custom fit to your client's body-shape, but it's extremely expensive, wouldn't work as well if the client ever gained or lost weight, and took forever to build, with your unhappy client standing around the whole time yelling at you to make it faster. Maybe you can build a super cheap chair real fast, but then this chair falls apart all the time and you need to keep on fixing it. Client got to sit down fast, which is great, but they keep on needing to get up so you can glue on more balsa wood to try to hold it together. You could get a stack of crates for them to sit on. Not really a chair, but it works, and you could then work on a nicer chair that won't fall apart instantly in the meantime. Or maybe they're happy enough with the stack of crates and say don't bother with the chair, i don't want to pay for it. And then maybe your client moves cross-country every year, and so will just toss the chair when they move, and find someone else to build them a new chair when they get to their new apartment.
  - couchand 6y ago
    The part missing from that analogy is the iterative process. Your client may have asked you to build a chair, but until they sit down on what you've built they don't realize that what they really wanted was a couch.
  - justinclift 6y ago
    Furniture rentals (aka FaaS) sounds like it'd suit this client more. :)
ilikebits 6y ago
I would argue that the region in a company's lifespan where craftsmanship matters is really between Series B and C. When you're trying to go from about 1M to 10M in revenue, and your engineering team is about 15 to 25 people, you have some interesting dynamics in play: 1. Everybody is swamped. Sales is now scaling up, which means new customers, new demands, and new fires every day. 2. The product's complexity has now grown tremendously. No single person, not even founding engineers, can fit the entire system in their head now. Very few people are equipped to even dig in to the more esoteric pieces and understand how and why they work, because enough time has passed that any context that was undocumented is either forgotten or hidden deep in a random person's head, and very little was documented (not necessarily the wrong choice - the time saved on not documenting things likely contributed to the company moving quickly enough and surviving to this stage). 3. Hiring has been approximately solved, and occurs on an approximately predictable cadence. Your engineering team has a small but predictable stream of newcomers. Every year or so, the team doubles. In this region, you have some interesting constraints to deal with: 1. Building new features is necessary to increase revenue, but each new feature has rapidly increasing marginal cost (due to overall system complexity). Therefore, we need more throughput. 2. Adding new engineers is necessary to increase throughput, but each additional engineer now provides rapidly diminishing marginal throughput. There are many tactics for succeeding in this region. The general focus here is "increase marginal throughput per engineer". Some not-writing-code tactics include investing in solid onboarding, developing effective documentation at the system level, and narrowing focus on product initiatives (becoming more deliberate with "we will try experiments A, B, and C in this order" as opposed to "we will throw the kitchen sink at the problem and see what sticks"). From a "writing code" perspective, I think this is where craftsmanship really shines. Constructing abstractions that dramatically increase the productivity of each marginal engineer provides an enormous pay-off in this region. Of course, the correct engineering abstractions must also be coupled with the correct engineering team structure. The effects of Conway's Law in this region are felt very, very strongly. Unfortunately, I think it is rather unlikely for someone to just be able to drop in to a company in this region and begin working on this kind of neat problem. I think the most likely ways to get to work on this are: - Be there from early on (arguably, first 5 or 10 engineers). Having domain experience is extraordinarily helpful in understanding which systems will be force multipliers. - Be very, very experienced. I can see a role for a senior staff engineer to be hired in at this point to help build these force multipliers. I think this person would need to have previous experience in companies of this size to correctly value domain experience and judge the right pieces to build. - Join in this region, and work with on the team of one of the two people above.
GuiA 6y ago
Craftsmanship is most visible in mature open source projects who have reached certain stability when it comes to features. The role of developers on those projects is more akin to stewards, watching over it for the current and next generation, rather than just shipping things out the door asap to meet the next milestone. SQLite is a great example that was recently discussed on HN.
gundmc 6y ago
The vast, vast majority of software written is done at neither a startup struggling for survival nor a tech giant monopoly.
- 6510 6y ago
  If it moves fast and breaks things get rid of it asap.
  - cvs268 6y ago
    (like a 10year old kid) ...encourage it to "grow-up" and mature.
- dgb23 6y ago
  I agree. I guess most of us, me included do client/project based work im some form. But the problem is still there, just in a different way: it is hard to convince people to pay extra for invisible results. Robustness, security, maintenance are often only visible some time after the initial proposal. So it becomes an issue of trust and communication rather than engineering.
- bryanlarsen 6y ago
  The vast majority of software is written at non-software companies. Software there is a cost centre and not a core competency, so craftsmanship is not valued there either.
  - noir_lord 6y ago
    Welcome to my life, it pays well but the rewards aren’t in the work of writing software, I like mentoring though so it’s not all negative.
  - dcposch 6y ago
    Imagine if buildings were bought by people who'd only ever see them from the outside. No inspection. They don't even see the plans, just an exterior render before they greenlight. Imagine how dysfunctional architecture and construction would be in that world. Software is uniquely intangible. Collectively we spend billions developing software every year, but often the decision maker never sees the codebase, only the UI. And you're right, the problem is multiplied at companies that consider software a cost. This is why projects like Jepsen are so powerful. Or Acid3 back in the day. They let a non-technical audience see the underlying implementation quality of different software efforts. We need a lot more where those two came from. Basic example. Why can't I go to any app in the app store and see the average hours between crashes? Software craftsmanship will suck until we make it visible.
foobarbecue 6y ago
Craftsmanship by Buck 65: https://music.youtube.com/watch?v=4_zKjSIPd6U&feature=share https://music.youtube.com/watch?v=4_zKjSIPd6U&feature=share
artsyca 6y ago
The argument has little do do with software in actual fact. What it boils down to in long-term strategy and investment. Building things well so they may serve you for years and years is a form of investment in the long term. There is a business philosophy credited to Japanese business but evident elsewhere too that thinking, planning and strategy should be as long term as possible, to a ridiculous extent. I read the biography of Akio Morita, the founder of Sony and while I'm sure it was somewhat biased to laud his achievements, even from the early post-war era manufacturing recording equipment for high end use, in what can be called "start-up mode" the emphasis was on building things of very high quality that would last. Truly this long term planning mindset is a manifestation of DRY, don't repeat yourself, and is crucial to survival of a nascent business. The whole disposable software attitude "we'll revisit once we ship" attitude is sinking you before you ever get off the ground.
- paulryanrogers 6y ago
  Yet Nintendo had resisted a significant online component in their games and platforms for two generations of consoles.
  - artsyca 6y ago
    That's actually part of it my dude. Nintendo is a centuries old company they move using old boring technologies. They only go in when they know they can go in all the way.. You know what I'm saying? In their home demographic people were not ready for online gaming until recent years. With long term investment comes a certain kind of risk appetite. It's the same reason banks haven't jumped into crypto or why so many enterprises continue using Java.. But I'm glad you used Nintendo as an example, being a software company. How about SNK or Capcom or Konami? You know what it's like getting blacklisted for jumping ship from one of these companies?
    - dnh44 6y ago
      Can you go into a bit more detail about the blacklisting? I’ve never heard anything like that but it fits with something I read recently that the team that built Zelda Breath of the Wild had also been involved in making Majoras Mask.
forgotmypw17 6y ago
I'm writing something designed to last, and here is how I am doing it: 1) I am doing it by myself, without any corporate sponsors or financial pay. 2) I am writing it in such a way that it could have already been working for 25 years.
- juststeve 6y ago
  What language do you choose? Possibly c or java?
  - 6510 6y ago
    FORTRAN
    - RMPR 6y ago
      Real programmers use Butterflies https://xkcd.com/378/ https://xkcd.com/378/
  - forgotmypw17 6y ago
    I chose: Perl as the primary language HTML/CSS for front-end JavaScript for optional front-end enhancements txt as the base data format SQLite for cache and indexing PHP for optional server connectors PGP for the identity system
- craz8 6y ago
  There is code in Microsoft Outlook that, although updated over the years, is essentially the same file format as it was in 1994 - and the code is unlikely to have been entirely rewritten in that time In 2010, Microsoft published the PST file format, and the latest documentation was updated this year That code was started in 1992, and first shipped in 1995 - 25 years in the wild! https://docs.microsoft.com/en-us/openspecs/office_file_formats/ms-pst/141923d5-15ab-4ef1-a524-6dce75aae546 https://docs.microsoft.com/en-us/openspecs/office_file_forma...
- thundergolfer 6y ago
  I like that 2nd criteria. Seems like a smart way to avoid components that are much more likely to get software decay. Have you been programming for 25 years?
robto 6y ago
I think you could argue that there is a third basic mode of development - the free and open source software. I'm not saying all FOSS software is artisan or cared for with excellent craftsmanship, but when I think of software that lasts FOSS software is what comes to mind: - emacs - PostgreSQL - linux I really like the Postgres example because it was initially just a bunch of academics who refused to implement new SQL features until they could do it The Right Way. See how long it took them to get upsert. I really hope that GNU Guix takes off in this way - just gradually doing things The Right Way until the product is just the default institution.
- l0b0 6y ago
  Some of the FOSS greats really seem to be built to last. I totally expect to still be using Linux, Firefox, Postgres, VLC, and heaps more decades from now. So why are there so many day-to-day tasks which are still just painful using the most popular tools available? IDEs, email clients, calendars, WYSIWYG editors and spreadsheets are still decades behind their closed source counterparts.
  - ac29 6y ago
    > email clients, calendars, WYSIWYG editors and spreadsheets The web killed serious desktop development of these outside of Microsoft. Google's services are good enough for everyone else, and run pretty much everywhere that has a reasonably modern web browser. As a desktop Linux user for the past ~2 decades, I'm mostly happy about this.
raz32dust 6y ago
I think large companies definitely have a lot to gain by building good software designed to last, and the best companies do place value in doing things right (I worked in a couple of monopolistic giants). Especially infrastructure has to be designed to last since they take a long time to build in the first place. If you value craftsmanship, infrastructure teams in large companies are probably a good place to be.
closeparen 6y ago
The departments of gigacorps that do software engineering well can execute circles around the others. A corporation's internal economy doesn't always or even usually care about that, but sometimes it does.

intrepidhero 6y ago

This argument can be made in a lot of industries. Farming, furniture making, automotive, consumer electronics, appliances... There are things we can do (and I'd argue we should) systemically to incentivise building for the long term but I think the cultural mindset needs to change first. I hesitate to lay all the blame on consumerism, but it certainly seems like a big part of the problem. I hope that projects like The Long Now and Artemis signal a shift toward thinking more about future generations.

6510 6y ago
The market system is an epic hack, it does fantastic stuff but it is merely a hack. We won't be able to do everything outside its scope. It is a really large scope but not large enough.
jmchuster 6y ago
Furniture-making actually seems like something you can draw a lot of intuitive analogies from. You need to make a chair so your client can sit down and work at their desk. While waiting on this chair, your client needs to stand awkwardly at their desk. So they care about how long it takes for you to make this chair, as well as how much it costs and all the normal stuff. You can build a very fancy premium chair custom fit to your client's body-shape, but it's extremely expensive, wouldn't work as well if the client ever gained or lost weight, and took forever to build, with your unhappy client standing around the whole time yelling at you to make it faster. Maybe you can build a super cheap chair real fast, but then this chair falls apart all the time and you need to keep on fixing it. Client got to sit down fast, which is great, but they keep on needing to get up so you can glue on more balsa wood to try to hold it together. You could get a stack of crates for them to sit on. Not really a chair, but it works, and you could then work on a nicer chair that won't fall apart instantly in the meantime. Or maybe they're happy enough with the stack of crates and say don't bother with the chair, i don't want to pay for it. And then maybe your client moves cross-country every year, and so will just toss the chair when they move, and find someone else to build them a new chair when they get to their new apartment.
- couchand 6y ago
  The part missing from that analogy is the iterative process. Your client may have asked you to build a chair, but until they sit down on what you've built they don't realize that what they really wanted was a couch.
- justinclift 6y ago
  Furniture rentals (aka FaaS) sounds like it'd suit this client more. :)

ilikebits 6y ago

I would argue that the region in a company's lifespan where craftsmanship matters is really between Series B and C. When you're trying to go from about 1M to 10M in revenue, and your engineering team is about 15 to 25 people, you have some interesting dynamics in play: 1. Everybody is swamped. Sales is now scaling up, which means new customers, new demands, and new fires every day. 2. The product's complexity has now grown tremendously. No single person, not even founding engineers, can fit the entire system in their head now. Very few people are equipped to even dig in to the more esoteric pieces and understand how and why they work, because enough time has passed that any context that was undocumented is either forgotten or hidden deep in a random person's head, and very little was documented (not necessarily the wrong choice - the time saved on not documenting things likely contributed to the company moving quickly enough and surviving to this stage). 3. Hiring has been approximately solved, and occurs on an approximately predictable cadence. Your engineering team has a small but predictable stream of newcomers. Every year or so, the team doubles. In this region, you have some interesting constraints to deal with: 1. Building new features is necessary to increase revenue, but each new feature has rapidly increasing marginal cost (due to overall system complexity). Therefore, we need more throughput. 2. Adding new engineers is necessary to increase throughput, but each additional engineer now provides rapidly diminishing marginal throughput. There are many tactics for succeeding in this region. The general focus here is "increase marginal throughput per engineer". Some not-writing-code tactics include investing in solid onboarding, developing effective documentation at the system level, and narrowing focus on product initiatives (becoming more deliberate with "we will try experiments A, B, and C in this order" as opposed to "we will throw the kitchen sink at the problem and see what sticks"). From a "writing code" perspective, I think this is where craftsmanship really shines. Constructing abstractions that dramatically increase the productivity of each marginal engineer provides an enormous pay-off in this region. Of course, the correct engineering abstractions must also be coupled with the correct engineering team structure. The effects of Conway's Law in this region are felt very, very strongly. Unfortunately, I think it is rather unlikely for someone to just be able to drop in to a company in this region and begin working on this kind of neat problem. I think the most likely ways to get to work on this are: - Be there from early on (arguably, first 5 or 10 engineers). Having domain experience is extraordinarily helpful in understanding which systems will be force multipliers. - Be very, very experienced. I can see a role for a senior staff engineer to be hired in at this point to help build these force multipliers. I think this person would need to have previous experience in companies of this size to correctly value domain experience and judge the right pieces to build. - Join in this region, and work with on the team of one of the two people above.

GuiA 6y ago

Craftsmanship is most visible in mature open source projects who have reached certain stability when it comes to features. The role of developers on those projects is more akin to stewards, watching over it for the current and next generation, rather than just shipping things out the door asap to meet the next milestone. SQLite is a great example that was recently discussed on HN.

gundmc 6y ago

The vast, vast majority of software written is done at neither a startup struggling for survival nor a tech giant monopoly.

6510 6y ago
If it moves fast and breaks things get rid of it asap.
- cvs268 6y ago
  (like a 10year old kid) ...encourage it to "grow-up" and mature.
dgb23 6y ago
I agree. I guess most of us, me included do client/project based work im some form. But the problem is still there, just in a different way: it is hard to convince people to pay extra for invisible results. Robustness, security, maintenance are often only visible some time after the initial proposal. So it becomes an issue of trust and communication rather than engineering.
bryanlarsen 6y ago
The vast majority of software is written at non-software companies. Software there is a cost centre and not a core competency, so craftsmanship is not valued there either.
- noir_lord 6y ago
  Welcome to my life, it pays well but the rewards aren’t in the work of writing software, I like mentoring though so it’s not all negative.
- dcposch 6y ago
  Imagine if buildings were bought by people who'd only ever see them from the outside. No inspection. They don't even see the plans, just an exterior render before they greenlight. Imagine how dysfunctional architecture and construction would be in that world. Software is uniquely intangible. Collectively we spend billions developing software every year, but often the decision maker never sees the codebase, only the UI. And you're right, the problem is multiplied at companies that consider software a cost. This is why projects like Jepsen are so powerful. Or Acid3 back in the day. They let a non-technical audience see the underlying implementation quality of different software efforts. We need a lot more where those two came from. Basic example. Why can't I go to any app in the app store and see the average hours between crashes? Software craftsmanship will suck until we make it visible.

foobarbecue 6y ago

Craftsmanship by Buck 65: https://music.youtube.com/watch?v=4_zKjSIPd6U&feature=share https://music.youtube.com/watch?v=4_zKjSIPd6U&feature=share

artsyca 6y ago

The argument has little do do with software in actual fact. What it boils down to in long-term strategy and investment. Building things well so they may serve you for years and years is a form of investment in the long term. There is a business philosophy credited to Japanese business but evident elsewhere too that thinking, planning and strategy should be as long term as possible, to a ridiculous extent. I read the biography of Akio Morita, the founder of Sony and while I'm sure it was somewhat biased to laud his achievements, even from the early post-war era manufacturing recording equipment for high end use, in what can be called "start-up mode" the emphasis was on building things of very high quality that would last. Truly this long term planning mindset is a manifestation of DRY, don't repeat yourself, and is crucial to survival of a nascent business. The whole disposable software attitude "we'll revisit once we ship" attitude is sinking you before you ever get off the ground.

paulryanrogers 6y ago
Yet Nintendo had resisted a significant online component in their games and platforms for two generations of consoles.
- artsyca 6y ago
  That's actually part of it my dude. Nintendo is a centuries old company they move using old boring technologies. They only go in when they know they can go in all the way.. You know what I'm saying? In their home demographic people were not ready for online gaming until recent years. With long term investment comes a certain kind of risk appetite. It's the same reason banks haven't jumped into crypto or why so many enterprises continue using Java.. But I'm glad you used Nintendo as an example, being a software company. How about SNK or Capcom or Konami? You know what it's like getting blacklisted for jumping ship from one of these companies?
  - dnh44 6y ago
    Can you go into a bit more detail about the blacklisting? I’ve never heard anything like that but it fits with something I read recently that the team that built Zelda Breath of the Wild had also been involved in making Majoras Mask.

forgotmypw17 6y ago

I'm writing something designed to last, and here is how I am doing it: 1) I am doing it by myself, without any corporate sponsors or financial pay. 2) I am writing it in such a way that it could have already been working for 25 years.

juststeve 6y ago
What language do you choose? Possibly c or java?
- 6510 6y ago
  FORTRAN
  - RMPR 6y ago
    Real programmers use Butterflies https://xkcd.com/378/ https://xkcd.com/378/
- forgotmypw17 6y ago
  I chose: Perl as the primary language HTML/CSS for front-end JavaScript for optional front-end enhancements txt as the base data format SQLite for cache and indexing PHP for optional server connectors PGP for the identity system
craz8 6y ago
There is code in Microsoft Outlook that, although updated over the years, is essentially the same file format as it was in 1994 - and the code is unlikely to have been entirely rewritten in that time In 2010, Microsoft published the PST file format, and the latest documentation was updated this year That code was started in 1992, and first shipped in 1995 - 25 years in the wild! https://docs.microsoft.com/en-us/openspecs/office_file_formats/ms-pst/141923d5-15ab-4ef1-a524-6dce75aae546 https://docs.microsoft.com/en-us/openspecs/office_file_forma...
thundergolfer 6y ago
I like that 2nd criteria. Seems like a smart way to avoid components that are much more likely to get software decay. Have you been programming for 25 years?

robto 6y ago

I think you could argue that there is a third basic mode of development - the free and open source software. I'm not saying all FOSS software is artisan or cared for with excellent craftsmanship, but when I think of software that lasts FOSS software is what comes to mind: - emacs - PostgreSQL - linux I really like the Postgres example because it was initially just a bunch of academics who refused to implement new SQL features until they could do it The Right Way. See how long it took them to get upsert. I really hope that GNU Guix takes off in this way - just gradually doing things The Right Way until the product is just the default institution.

l0b0 6y ago
Some of the FOSS greats really seem to be built to last. I totally expect to still be using Linux, Firefox, Postgres, VLC, and heaps more decades from now. So why are there so many day-to-day tasks which are still just painful using the most popular tools available? IDEs, email clients, calendars, WYSIWYG editors and spreadsheets are still decades behind their closed source counterparts.
- ac29 6y ago
  > email clients, calendars, WYSIWYG editors and spreadsheets The web killed serious desktop development of these outside of Microsoft. Google's services are good enough for everyone else, and run pretty much everywhere that has a reasonably modern web browser. As a desktop Linux user for the past ~2 decades, I'm mostly happy about this.

raz32dust 6y ago

I think large companies definitely have a lot to gain by building good software designed to last, and the best companies do place value in doing things right (I worked in a couple of monopolistic giants). Especially infrastructure has to be designed to last since they take a long time to build in the first place. If you value craftsmanship, infrastructure teams in large companies are probably a good place to be.

closeparen 6y ago

The departments of gigacorps that do software engineering well can execute circles around the others. A corporation's internal economy doesn't always or even usually care about that, but sometimes it does.