4 ms·

Programming is still a craft, not engineering, or manufacturing. A software house should work like bespoke tailoring, or fine cabinetry, or glass blowing. Ther

by rswail 3y ago

Programming is still a craft, not engineering, or manufacturing. A software house should work like bespoke tailoring, or fine cabinetry, or glass blowing. There's still no better training for programming than the equivalent of master/journeyman/apprentice. Apologies for the gender specific terms, but they are specific to how tradespeople operated from medieval times. The worst thing to ever happen to the practice of business is the invention of the MBA. MBAs are imbued with the misleading axiom that management is a craft and science of its own, independent of the type of process or practice that is being managed. Combined with endless selling of the latest buzzword theories by consultants is why we end up with JIRA-Driven-Development, nonsense like t-shirt sizes, 2 hour wankfests called "Sprint Reviews", let alone all the scrumming and standing-up and backlog-refining and endless make work.

plz-no-soy 3y ago
[flagged]
pif 3y ago
> Apologies for the gender specific terms, It doesn't make any sense to apologize for using a language in its current form.
- dsr_ 3y ago
  All living languages are in some state of flux. That's how you can tell they are still alive.
  - pif 3y ago
    I've not stated the opposite.
  - plz-no-soy 3y ago
    [flagged]
- TeMPOraL 3y ago
  It comes out of an abundance of caution, necessary in these uncertain times.
happymellon 3y ago
All of those things have value if they are allowed to provide value. None provide value if management do not allow it to have value. > t-shirt sizes The whole point of planning poker is for people to guesstimate how much they think a task will take, and the poi t of doing it in a group is to allow the team to discuss the things they may not have thought about. > 2 hour sprint reviews I would agree that 2 hours is vastly excessive, but a sprint review is just a time for people to regularly meet and say what things are pissing them off, and what can be done to fix them. If management know best and you have to use a shitty Jenkins pipeline with someone else's scripts, then it is pointless. But that's not the fault of the sprint review.
- genghisjahn 3y ago
  Planing poker is the one ceremony that I find consistently helpful. Listening to different devs discuss why they think something is 13 points or 3 points is helpful to the whole team. You could change the names of all the parts of the meeting, but having the discussion about differing opinions on complexity is so helpful.
  - smoe 3y ago
    I do like the planning poker for the same reason. I just find that people use story points overly granular. E.g. when using Fibonacci series, what is the point spending time discussing the minute difference between 1,2 and 3 points. What I have liked in the past, is just using small, medium, large or unactionable. Or with the right team/managment, not using estimates at all, just have people pick up the tasks they feel confident that they can get done within a given time frame after having the discussion in the group about differing opinions on complexity.
    - eterm 3y ago
      There's more difference between 2 points and 3 points than between 5 points and 8. If you're looking to fill an arbitrary bucket, relative size matters most.
underlipton 3y ago
>There's still no better training for programming than the equivalent of master/journeyman/apprentice. This is inseparable from the fact that programming is still a domain dominated by white males from upper middle-class families (and immigrants from countries with functional, non-boondoggle professional training and/or demoscene). DEI as a rainbow-wash goes away when organic mentorship of black kids and young women happens en masse.
- x86x87 3y ago
  I'm not following what your point is. Would there be a way to make everyone expendable faster is it wasn't just white entitled dudes?
  - underlipton 3y ago
    >I'm not following what your point is. I'm not sure how I could be clearer. >Would there be a way to make everyone expendable faster is it wasn't just white entitled dudes? You might want to check this for errors.
    - bluecheese452 3y ago
      I am not following your point either. Surely there must be a way to reword it?
      - underlipton 3y ago
        It would help if someone would articulate what is unclear. Forgive me, but on this subject, I've encountered many who are fully capable of understanding, but would rather not. So I'd ask that you try harder. Perhaps restate what you think I mean, and I can correct you if it's mistaken?
- throwaway60703 3y ago
  I'm absolutely certain there are much more non-white (Indian, Chinese, Vietnamese...) programmers than white. And if we stop with the racism, are you sure it's not the programming that made these guys upper middle class?
plz-no-soy 3y ago
[flagged]
too-much-s0yb0y 3y ago
[flagged]
kspacewalk2 3y ago
None of what you're saying is an absolute truth. It applies in many environments, and in many others there is definitely space for commodification and MBA-style management gimmicks. It all depends on scale, technical complexity & maturity of the product, centrality of the software in question to the core product, etc.
- Retric 3y ago
  Hardly, you’re confusing risk for commodification. It’s possible for an an incompetent plumber to fix your plumbing problems by accident, expertise is about consistency. The dirty little secret is MBA led projects constantly fail in a truly spectacular fashion.
- FrustratedMonky 3y ago
  Exactly Like, there are mass produced furniture shops. (Say, building chat bot clones, or flappy bird clones). The basic layout/shape/function, is known and being tweaked. Then there is the custom built furniture. I need an 18th century armoire. The 'Bespoke', a custom application for some odd business need, or solving a new problem. We do often discuss these by squishing 'Software Engineering' into a single bucket and it leads to many arguments around really different things.
pclmulqdq 3y ago
Engineering is also a craft, but we have figured out how to manage it. The same will happen to programming (if it hasn't already). This happens to all crafts, from weaving to nuclear engineering.
borlanco 3y ago
> Programming is still a craft, not engineering, or manufacturing. Programming can be engineering if you know how to do it. Engineering is, in a nutshell, a set of principles you learn and apply, and never deviate from, in work and life. Engineers always deliver the highest quality. Craftspersons do not know these engineering principles, or they disregard them. They invariably deliver faster than engineers, and their output is always simpler and of lower quality. In "The Rise of Worse is Better" [0], an engineer (from MIT) debates with a craftsman (from Berkeley). The Berkeley guy cheerfully admits he is disregarding an engineering principle (correctness), and that's why "the MIT guy did not like this solution because it was not the right thing". [0] The Rise of Worse is Better https://dreamsongs.com/RiseOfWorseIsBetter.html https://dreamsongs.com/RiseOfWorseIsBetter.html
- dustingetz 3y ago
  what are the engineering principles of software? does team A agree with team B what they are? is there alignment between academia and industry? Electrical engineering has Maxwells Laws and math. What is the math of software? Do teams A and B agree?
  - kevin_thibedeau 3y ago
    Engineering is about applying repeatable processes to achieve a specified result. Suitable analysis is performed before starting on the final work product to ensure the results are achievable. No process, no specification, and no analysis means no engineering.
  - borlanco 3y ago
    The best book about the application of engineering principles to software is SICP [0]. Abelson and Sussman wrote SICP to illustrate the principles. Everything else in SICP is some means to that end. They reveal that SICP is about engineering in the Preface to the First Edition: > The techniques we teach and draw upon are common to all of engineering design. We control complexity by building abstractions that hide details when appropriate. We control complexity by establishing conventional interfaces that enable us to construct systems by combining standard, well-understood pieces in a "mix and match" way. We control complexity by establishing new languages for describing a design, each of which emphasizes particular aspects of the design and deemphasizes others. [0] Structure and Interpretation of Computer Programs, second edition. Harold Abelson and Gerald Jay Sussman. https://mitp-content-server.mit.edu/books/content/sectbyfn/books_pres_0/6515/sicp.zip/full-text/book/book.html https://mitp-content-server.mit.edu/books/content/sectbyfn/b...
swatcoder 3y ago
I approach the work like this and appreciate others who do, but it doesn't scale. It's engaging and fun and can produce more elegant, attentive, humanized work. But larger technology organizations (or organizations pursuing larger projects) need to draw on engineering and factory models to meet their software development needs the same way that IKEA and GM draw on them. Just like in software, there are still countless master woodworkers and master mechanics who bring beautiful attention to their craft, but there is also a scale where that approach is simply not suitable. The different scales coexist and even comingle, and they're all valid.
deleted 3y ago
[deleted]
artyom 3y ago
> master/journeyman/apprentice Even if it's the way I learnt, it's just one way to learn. I'm in software but my background is electronics engineering. But I can say electronics can be a craft (just build some stuff), or engineering (all the way to knowledge of modern physics, telecommunications, semiconductors design), or manufacturing (build some stuff at scale). Same applies to programming. I've known quite a few people with computer science backgrounds. Some would have a level of comprehension and ability that's just unachievable by just practicing programming as a craft, and some others can determine any algorithm Big O notation at first glance but can't write 5 lines of code if their life depends on it.
justincredible 3y ago
[dead]
deleted 3y ago
[deleted]

by rswail 3y ago

plz-no-soy 3y ago

[flagged]

pif 3y ago

> Apologies for the gender specific terms, It doesn't make any sense to apologize for using a language in its current form.

dsr_ 3y ago
All living languages are in some state of flux. That's how you can tell they are still alive.
- pif 3y ago
  I've not stated the opposite.
- plz-no-soy 3y ago
  [flagged]
TeMPOraL 3y ago
It comes out of an abundance of caution, necessary in these uncertain times.

happymellon 3y ago

All of those things have value if they are allowed to provide value. None provide value if management do not allow it to have value. > t-shirt sizes The whole point of planning poker is for people to guesstimate how much they think a task will take, and the poi t of doing it in a group is to allow the team to discuss the things they may not have thought about. > 2 hour sprint reviews I would agree that 2 hours is vastly excessive, but a sprint review is just a time for people to regularly meet and say what things are pissing them off, and what can be done to fix them. If management know best and you have to use a shitty Jenkins pipeline with someone else's scripts, then it is pointless. But that's not the fault of the sprint review.

genghisjahn 3y ago
Planing poker is the one ceremony that I find consistently helpful. Listening to different devs discuss why they think something is 13 points or 3 points is helpful to the whole team. You could change the names of all the parts of the meeting, but having the discussion about differing opinions on complexity is so helpful.
- smoe 3y ago
  I do like the planning poker for the same reason. I just find that people use story points overly granular. E.g. when using Fibonacci series, what is the point spending time discussing the minute difference between 1,2 and 3 points. What I have liked in the past, is just using small, medium, large or unactionable. Or with the right team/managment, not using estimates at all, just have people pick up the tasks they feel confident that they can get done within a given time frame after having the discussion in the group about differing opinions on complexity.
  - eterm 3y ago
    There's more difference between 2 points and 3 points than between 5 points and 8. If you're looking to fill an arbitrary bucket, relative size matters most.

underlipton 3y ago

>There's still no better training for programming than the equivalent of master/journeyman/apprentice. This is inseparable from the fact that programming is still a domain dominated by white males from upper middle-class families (and immigrants from countries with functional, non-boondoggle professional training and/or demoscene). DEI as a rainbow-wash goes away when organic mentorship of black kids and young women happens en masse.

x86x87 3y ago
I'm not following what your point is. Would there be a way to make everyone expendable faster is it wasn't just white entitled dudes?
- underlipton 3y ago
  >I'm not following what your point is. I'm not sure how I could be clearer. >Would there be a way to make everyone expendable faster is it wasn't just white entitled dudes? You might want to check this for errors.
  - bluecheese452 3y ago
    I am not following your point either. Surely there must be a way to reword it?
    - underlipton 3y ago
      It would help if someone would articulate what is unclear. Forgive me, but on this subject, I've encountered many who are fully capable of understanding, but would rather not. So I'd ask that you try harder. Perhaps restate what you think I mean, and I can correct you if it's mistaken?
throwaway60703 3y ago
I'm absolutely certain there are much more non-white (Indian, Chinese, Vietnamese...) programmers than white. And if we stop with the racism, are you sure it's not the programming that made these guys upper middle class?

plz-no-soy 3y ago

[flagged]

too-much-s0yb0y 3y ago

[flagged]

kspacewalk2 3y ago

None of what you're saying is an absolute truth. It applies in many environments, and in many others there is definitely space for commodification and MBA-style management gimmicks. It all depends on scale, technical complexity & maturity of the product, centrality of the software in question to the core product, etc.

Retric 3y ago
Hardly, you’re confusing risk for commodification. It’s possible for an an incompetent plumber to fix your plumbing problems by accident, expertise is about consistency. The dirty little secret is MBA led projects constantly fail in a truly spectacular fashion.
FrustratedMonky 3y ago
Exactly Like, there are mass produced furniture shops. (Say, building chat bot clones, or flappy bird clones). The basic layout/shape/function, is known and being tweaked. Then there is the custom built furniture. I need an 18th century armoire. The 'Bespoke', a custom application for some odd business need, or solving a new problem. We do often discuss these by squishing 'Software Engineering' into a single bucket and it leads to many arguments around really different things.

pclmulqdq 3y ago

Engineering is also a craft, but we have figured out how to manage it. The same will happen to programming (if it hasn't already). This happens to all crafts, from weaving to nuclear engineering.

borlanco 3y ago

> Programming is still a craft, not engineering, or manufacturing. Programming can be engineering if you know how to do it. Engineering is, in a nutshell, a set of principles you learn and apply, and never deviate from, in work and life. Engineers always deliver the highest quality. Craftspersons do not know these engineering principles, or they disregard them. They invariably deliver faster than engineers, and their output is always simpler and of lower quality. In "The Rise of Worse is Better" [0], an engineer (from MIT) debates with a craftsman (from Berkeley). The Berkeley guy cheerfully admits he is disregarding an engineering principle (correctness), and that's why "the MIT guy did not like this solution because it was not the right thing". [0] The Rise of Worse is Better https://dreamsongs.com/RiseOfWorseIsBetter.html https://dreamsongs.com/RiseOfWorseIsBetter.html

dustingetz 3y ago
what are the engineering principles of software? does team A agree with team B what they are? is there alignment between academia and industry? Electrical engineering has Maxwells Laws and math. What is the math of software? Do teams A and B agree?
- kevin_thibedeau 3y ago
  Engineering is about applying repeatable processes to achieve a specified result. Suitable analysis is performed before starting on the final work product to ensure the results are achievable. No process, no specification, and no analysis means no engineering.
- borlanco 3y ago
  The best book about the application of engineering principles to software is SICP [0]. Abelson and Sussman wrote SICP to illustrate the principles. Everything else in SICP is some means to that end. They reveal that SICP is about engineering in the Preface to the First Edition: > The techniques we teach and draw upon are common to all of engineering design. We control complexity by building abstractions that hide details when appropriate. We control complexity by establishing conventional interfaces that enable us to construct systems by combining standard, well-understood pieces in a "mix and match" way. We control complexity by establishing new languages for describing a design, each of which emphasizes particular aspects of the design and deemphasizes others. [0] Structure and Interpretation of Computer Programs, second edition. Harold Abelson and Gerald Jay Sussman. https://mitp-content-server.mit.edu/books/content/sectbyfn/books_pres_0/6515/sicp.zip/full-text/book/book.html https://mitp-content-server.mit.edu/books/content/sectbyfn/b...

swatcoder 3y ago

I approach the work like this and appreciate others who do, but it doesn't scale. It's engaging and fun and can produce more elegant, attentive, humanized work. But larger technology organizations (or organizations pursuing larger projects) need to draw on engineering and factory models to meet their software development needs the same way that IKEA and GM draw on them. Just like in software, there are still countless master woodworkers and master mechanics who bring beautiful attention to their craft, but there is also a scale where that approach is simply not suitable. The different scales coexist and even comingle, and they're all valid.

deleted 3y ago

[deleted]

artyom 3y ago

> master/journeyman/apprentice Even if it's the way I learnt, it's just one way to learn. I'm in software but my background is electronics engineering. But I can say electronics can be a craft (just build some stuff), or engineering (all the way to knowledge of modern physics, telecommunications, semiconductors design), or manufacturing (build some stuff at scale). Same applies to programming. I've known quite a few people with computer science backgrounds. Some would have a level of comprehension and ability that's just unachievable by just practicing programming as a craft, and some others can determine any algorithm Big O notation at first glance but can't write 5 lines of code if their life depends on it.

justincredible 3y ago

[dead]

deleted 3y ago

[deleted]