Live data from Hacker News

Heuristics for Effective Software Development: A continuously evolving list

holub.com

21–30 of 68 posts

Re: Heuristics for Effective Software Development: A continuously evolving list

#21
post #20
post #13

Earlier quoted context omitted.

The great thing about vague bullshit is that if you squint really hard, there's always a semi-plausible interpretation which makes sense. See also: fortune cookies, horoscopes.

You are right. But I read this as someones collection of ideas anways not as universal priciples that must be applied everywhere. I tend to favourably read into other peoples statements if in doubt (especially on HN)

> I tend to favourably read into other peoples statements if in doubt (especially on HN)

That's a commendable character trait, but if you have to twist a "heuristic" beyond recognizability for it to make any sense, then what's the purpose of that heuristic?

Re: Heuristics for Effective Software Development: A continuously evolving list

#22
post #8

Earlier quoted context omitted.

> * Use schema-based data storage Great idea until it isn't. The article is full of bullshit but one thing is very true. We can't predict the future, especially so when we deal with humans and society where stuff changes fast. Strict schemas are more pain than gain here. > * Use formal verification if possible Wonder when F* and the like get mainstream so that "if possible" becomes "almost always".

Schemas don't mean that formats can't evolve.

Schemas make formats easier to evolve.

Re: Heuristics for Effective Software Development: A continuously evolving list

#23

I wish there were a list for "effective actually completing your Kickstarter", wherein Holub took money for an "Agile video class" [1], which was supposed to be delivered in an Agile way. That was 4 years ago. First the timeline got pushed out, then I rather gather he's just got bored and drifted on. How ironic is the non-delivery of an agile training course, supposedly delivered in an agile way, that utterly fails t…

> Last Post: Module 1 released, more will follow shortly

> November 2, 2017

Lol

Re: Heuristics for Effective Software Development: A continuously evolving list

#24
> 6. Knowledge work has unique concerns, unrelated to those of a factory or construction site.

> 7. … You cannot improve a system by tinkering with the parts.

This last statement seems to apply more to factories or construction sites, not software engineering. Obviously systems can be improved by tinkering with parts that are shared and actively used by multiple systems.

Re: Heuristics for Effective Software Development: A continuously evolving list

#26

I wish there were a list for "effective actually completing your Kickstarter", wherein Holub took money for an "Agile video class" [1], which was supposed to be delivered in an Agile way. That was 4 years ago. First the timeline got pushed out, then I rather gather he's just got bored and drifted on. How ironic is the non-delivery of an agile training course, supposedly delivered in an agile way, that utterly fails t…

From his blog[1]

> External pressure (accountability) and internal pressure (responsibility) are simply not needed in a healthy culture. As in a relationship, the word “accountable” is rarely, if ever, heard in high functioning organizations.

I can't quite determine if he is ahead of his time or a snake oil salesman.

[1] https://holub.com/noaccountability/

Re: Heuristics for Effective Software Development: A continuously evolving list

#27
post #23

I wish there were a list for "effective actually completing your Kickstarter", wherein Holub took money for an "Agile video class" [1], which was supposed to be delivered in an Agile way. That was 4 years ago. First the timeline got pushed out, then I rather gather he's just got bored and drifted on. How ironic is the non-delivery of an agile training course, supposedly delivered in an agile way, that utterly fails t…

> Last Post: Module 1 released, more will follow shortly > November 2, 2017 Lol

Yeah, right?

Don't get me wrong, I've found a lot of Holub's content to be great. I'm something of a fan in some senses, as it's given me a perspective to question some of the utter guff prevalent in the agile space (particularly wrt. things like Scrum and Story points). I don't buy some of it - things like cost of delay - but I'm always interested to hear more and I'm prepared to change my mind on it.

But.

Much like Dawkins, he ought to stay off twitter, as he comes out with crazy-town absolutist statements (like: if your organisation doesn't do X, then it's fundamentally beyond all redemption and you should just leave).

A recurring theme is there in that list, particularly (20), which is - to paraphrase - "give all your money to the agile team, then go away and you have no right to question what they're doing in any way, shape, or form - you just trust them to 'do the right thing' as they're the experts". No line management, no project management, nothing. Go away and leave me alone.

Now put that in context of a self started project that took nearly $15K, listed no significant risks "hey I already have most of this content anyway", has no external dependencies to blame and... completely failed to deliver. How can I take any of it seriously when the supposed expert can so utterly fail to practice what they are preaching?

Re: Heuristics for Effective Software Development: A continuously evolving list

#28
I do a weekly roundup of tech stuff.[1] I flagged this story for inclusion, mostly because of the types of conversation I'm seeing on HN today.

This is not "New age bullshit", although I understand the sentiment. The most frustrating part about studying how teams self-manage for success is that management theory consists of a lot of words and emotions and very little concrete theory. That doesn't make any of it wrong; it just makes it very difficult to discuss in the same logical way we'd discuss, say a new theorem.

What's missing here is any sort of agreed-upon discernment function. Psychological safety is important. Ok. But how do we tell when we have that versus when we don't? Process exists in service of people. Ok, what does that mean? Should a process, for instance, inform people of things they don't like or want to hear? I would think that if a process wasn't ever uncomfortable, it's not much of a good process. But then again, we don't know.

The entire list is mostly like that. It's not things you can disagree with, it all sounds pretty good, but as a reader you're left with an empty feeling. Just what the heck am I supposed to do with this?

There's an old saying that much of being a management consultant is pandering to a natural type of person who wants to burn it all down. The rest of it is just telling clients what they already want to hear. It doesn't give those folks a good reputation.

Once again, though, it doesn't mean any of it is wrong, it's just intractable. As much as mankind has tried over and over again, it remains barbarously difficult to translate feel-good things we all instinctively know that work into practical and actionable advice, at least when it comes to knowledge work. (For assembly-line production/manufacturing work the situation is different, thank goodness)

I believe there's a lot of overstatement on both sides of this discussion, a lot of posturing and demagogurely, even by people who mean well and don't realize what they're doing. It's not that there's nothing there, it's that there is a lot of work still remaining. This is too important for all of us to simply bounce around off-the-walls about. There's something of value there. Let's go find it.

1. If you're interested in my weekly roundup, shameless plug: https://danielbmarkham.com

Re: Heuristics for Effective Software Development: A continuously evolving list

#29
post #14
post #5

Earlier quoted context omitted.

Interesting. Why function calls over events? And is it always applicable?

I suspect because it makes both data and control flow more explicit and traceable. > And is it always applicable? No heuristic is always applicable.

> No heuristic is always applicable.

Exactly. That's why it is called a heuristic and not a rule. :)

Re: Heuristics for Effective Software Development: A continuously evolving list

#30

> 6. Knowledge work has unique concerns, unrelated to those of a factory or construction site. > 7. … You cannot improve a system by tinkering with the parts. This last statement seems to apply more to factories or construction sites, not software engineering. Obviously systems can be improved by tinkering with parts that are shared and actively used by multiple systems.

Yeah he seems to be talking about social systems rather than software. But it's wrong in both cases. In software systems we have refactoring and bug fixing, in social systems we have organizational frameworks and roles that abstract away from the people. Both of those things have their limitations and problems, but I wouldn't go as far as the author in saying they are basically useless.
Post reply on HN