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.
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.
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.
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 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
Example: https://galois.com/
Example: https://inst.eecs.berkeley.edu/~cs162/sp13/hand-outs/They-Wr...
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.
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.
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.
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."
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.
If you're looking to fill an arbitrary bucket, relative size matters most.
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?".
+ 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.
Have a think and can you split it into two smaller tasks for the juniors to pick up.
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.
AFAIK, everybody that do it is cargo-culting.
It doesn't make any sense to apologize for using a language in its current form.
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.
And if we stop with the racism, are you sure it's not the programming that made these guys upper middle class?
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 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.
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?
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.