Hacker News Reader

Comment by rswail | Hacker News Reader

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.

View on HN

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.

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.

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.

In theory yes. Back on earth: I can argue that each task is 13 points. Usually this goes to being a pissing contest. The person that is deeply familiar with what needs to happen and has written this down (assuming written down not a one line to fix somthing) to be "estimated" probably is in the best position to acually do it/fix it. Also it's an insidious way to get the drones to fight each other trying to one up and show how smart they are. The person assigned to fixing it should estimate it (ie I have completely silenced "10x" developers by just telling them to just pick it up and do it if it's so easy).

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.

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.

Our team had so many planning poker sessions where we spent 12 people * 2 dev hours trying to figure out whether stories were a 2 or a 3, management finally said it is always a 3. We were literally spending more aggregate time trying to decide effort, than the actual effort it took to complete these tasks.

2 and 3 are equal. 5 and 8 are equal. The question is simply "Is this a couple days, the whole week, or the whole sprint?".

The only reasonable estimates, ever:

+ That's trivial, it will be ready for testing before lunch.

+ I know how to do that, should be ready tomorrow/next day.

+ I can see how to do that but there are lots of other constraints - at least a week, might be more.

+ It's a big project, needs more planning and specification before it becomes a series of estimable tasks. Let's do that.

+ That breaks other things we care about. We need to prioritize and be ready for rework.

If you want, you can call these small, medium and large.

I completely agree with these levels, but disagree with mapping them to “small, medium, and large.” That’s a lossy compression if you will, and the heart of the problem. A shorthand might start with good intentions, but rapidly is muddied by conflicting interests.

5-8 just means that you think that the task is getting a bit big.

Have a think and can you split it into two smaller tasks for the juniors to pick up.

Planning poker is only useful in the context of who may be doing the work, and even then I'm not sure how useful it really is. What is an 8 to one dev may be a 5 to another, as one may have a better grasp of the problem space than the other. In short, one shouldn't assume equality across the team for ability to do given task.

How is it helpful to the entire team for everyone to pay attention if adding a feature is 3 or 12 points? It's the one thing that wastes so much money and time. In the end it's 3 points. Thank you everyone for wasting $5,000

I think you might be confusing sprint review with sprint retrospective? What you describe is the sprint retrospective, and when teams are autonomous enough to actually act on their pain points, it's easily the most useful scrum ceremony, IMHO.

Sprint reviews are really kinda just a wankfest where people show nice graphs and demos for an audience that either already knows or doesn't care.

> it's easily the most useful scrum ceremony, IMHO.

Agreed. I would kill almost anything else from scrum (maybe weeklys can stay too. Sometimes they are useful), but sprint retros stay. And also agreed about the uselessness of sprint reviews. I've never been in one and thought later that I've learned anything or was useful to anyone in there. It's like going to church without being religious in villages. "The community would look with disgust at us if we weren't there on Sunday. So, we are there."

>The whole point of...

there are many things that in theory have a particular point but that when put in practice most often do not have any point at all - in such cases opinion seems to divide between those who complain that the people who put things in practice do so incorrectly and those who feel that if the practice when implemented tends to be wrong then it is the fault of the theory itself.

I personally hold with the latter view.

About sprint reviews in particular (not retrospective), do have a point in theory? I have never found anybody that can point to any.

AFAIK, everybody that do it is cargo-culting.

The theory of identifying something as being shit and then removing it is a bad thing?

That is not the theory, that is the goal. Sprint reviews have a goal of identifying something as being shit and then removing it, they have a theory as to how this will be achieved which is the sprint review process.

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.

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.

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.

> Apologies for the gender specific terms,

It doesn't make any sense to apologize for using a language in its current form.

All living languages are in some state of flux. That's how you can tell they are still alive.

I've not stated the opposite.

It comes out of an abundance of caution, necessary in these uncertain times.

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

> 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

> Engineers always deliver the highest quality.

Engineers deliver a cheaper product that still meets some known set of requirements with whatever safety margin.

The quality is as good as the requirements dictate.

A big reason why software is largely not engineering is because nobody knows wtf the requirements actually are, and the dependency stack is unknowably large

It's true that engineering principles are not usually applied in the software field, but if quality is the most important requirement, they are indispensable.

Example: https://galois.com/

Example: https://inst.eecs.berkeley.edu/~cs162/sp13/hand-outs/They-Wr...

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?

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/b...

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.

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.

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

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?

> I'm absolutely certain there are much more non-white (Indian, Chinese, Vietnamese...) programmers than white.

Worldwide, sure. I'm speaking about the US.

>And if we stop with the racism

That would be up to you. I haven't said anything that's racist.

>are you sure it's not the programming that made these guys upper middle class?

That would be even worse. It would mean that the white men who lived childhoods of lesser means and found success in the tech industry, presumably under the guidance of seniors who themselves (under your hypothetical) were more likely to be first-gen professionals, looked at black and brown kids in similar situations and thought, "Fuck you, got mine."

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?

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

I am not following your point either. Surely there must be a way to reword it?

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?

Reply on news.ycombinator.com