9 ms·

Heuristics for Effective Software Development: A continuously evolving list

121 points by dailymorn 5y ago

satisfice 5y ago
Sloppy thinking… new age bullshit… most of it collapses under mild scrutiny. Some of it is okay. I just don’t get, after decades and decades, how our industry continues to tolerate bullshit. Quality is not negotiable? Really? Negotiation is not collaboration? Really? This is not just wrong, it’s almost gaslighting.
- jimktrains2 5y ago
  I was going to pick a few to complain about, but there are just so many things on that list that are wrong or contradictory. Simple is a very relative thing, qnd not everything can be "simple". Not everything is a transient thing, especially if you're trying to improve ypur customers lives. Tinkering qith parts is often the only way to improve a system and setting your sights on changing everything at once is setting yourself up for being overwhelmed. It's just one overly-dogmatic, "new age bs" after another with little though to what the consequences of these heuristics would be.
- bartread 5y ago
  Agree. I was going to add cargo-cult, idealistic, and nonsense. I think reading this guy's list actually killed some brain cells. The problem is not just that we tolerate bullshit: we reward it. I'd bet he gets paid quite handsomely to trot out this bilge. Here's a thing close to my heart: "Knowledge work has unique concerns, unrelated to those of a factory or construction site." But notice how he doesn't talk about any specifics, or recognise that there are shades of difference in knowledge work: e.g., it's easier to make determinations about delivery when adding well-understood and tightly scoped CRUD pages, than it is when delivering a more R&D oriented outcome. Don't get me started on the Toyota nonsense though because we'll be here all day. Another bugbear: talking about outcome versus output without being specific about what you mean with these terms. Grr. And the first point about processes: they don't serve people, they serve business outcomes. Sometimes those things coincide; often they don't.
- atoav 5y ago
  > quality is not negotiable? Really? I read this as "certain principles must be upheld at any cost" and I agree with that. E.g. if your project is dealing with people's health data, not securing that database is a cut on quality you just shouldn't make. Or to phrase it the other way around: If your project cannot reach that basic quality level, maybe it should be ended right away, because it clearly lacks funding/resources. As a freelancer I wouldn't take that job. > Negotiation is not collaboration? Really? Well it can be, but it also can't be. The phrasing on this one is a bit vague. But if you read it as "just defending your interest and not trying to discuss common goals and the goals of the other side is not collaboration" it would be true again.
  - adwn 5y ago
    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.
    - atoav 5y ago
      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)
      - adwn 5y ago
        > 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?
        Verdex 5y ago
        Hard agree. A heuristic can only be said to work if it means the same thing to everyone. Like, if the list means anything to everyone, then how can we say that the list is responsible for success or failure? Otherwise what are we saying the causality is? Like, that the list is just somehow inspiring everyone to be successful? So, like, if we just believe enough in the list we'll get it done? No thanks. I'm not going to pray to some poetry.
- omginternets 5y ago
  You can really feel the thought leadership on this one, can’t you?
- UK-Al05 5y ago
  I mean you can have worse quality if you want. But won't have the effect you want. Aka speed. In fact the opposite is most likely to happen.
IshKebab 5y ago
Very woolly. I was expecting more concrete things like * Use static types * Use CI and version control * Use schema-based data storage * Prefer function calls to events * Use formal verification if possible etc.
- Ygg2 5y ago
  Interesting. Why function calls over events? And is it always applicable?
  - adwn 5y ago
    I suspect because it makes both data and control flow more explicit and traceable. > And is it always applicable? No heuristic is always applicable.
    - naavis 5y ago
      > No heuristic is always applicable. Exactly. That's why it is called a heuristic and not a rule. :)
  - IshKebab 5y ago
    Not always applicable but it makes debugging far easier, reduces the chance of events being lost and makes it easier and safer to understand and modify code.
- axelroze 5y ago
  > * 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".
  - IshKebab 5y ago
    Schemas don't mean that formats can't evolve.
cheradenine_uk 5y ago
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 to actually, y'know, deliver? []1 https://www.kickstarter.com/projects/1086486319/agility-with-allen-the-whole-caboodle-video-class/posts https://www.kickstarter.com/projects/1086486319/agility-with...
- Aeolun 5y ago
  > Last Post: Module 1 released, more will follow shortly > November 2, 2017 Lol
  - cheradenine_uk 5y ago
    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?
- dgb23 5y ago
  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/ https://holub.com/noaccountability/
seanhunter 5y ago
This list could have been generated by pointing GPT-3 at a list of self-help websites.
agge 5y ago
This resonates with my thinking as well. Although something I’ve always been missing from people talking about agile in general, is more specifics on how collaboration can happen. Especially collaboration with ”the customer” (customer is a terrible term). I’ve learnt so much more from reading blogs by Teresa Torres than from any agilist about how to actually learn from what you deliver.
eurasiantiger 5y ago
> 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.
- dgb23 5y ago
  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.
- yourenotsmart 5y ago
  From the article: > You cannot change anything without changing everything. You cannot improve a system by tinkering with the parts. Those sentences seem to outright contradict each other...
tpoacher 5y ago
"Negotiation is not collaboration". That's about the only soundbyte I liked from this list; but, on the plus side, I did like that soundbyte quite a lot!
DanielBMarkham 5y ago
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 https://danielbmarkham.com
- ycnews 5y ago
  re:"weekly roundup"> F# Is The Best Coding Language Today Have you looked at http://nim-lang.org http://nim-lang.org ?
wiz21c 5y ago
> 12. We work to make our customer’s lives better and their work easier. We do that by providing a steady stream of artifacts and aid that they find valuable. This guy must be on another astral plane :-) Who is the customer ? Ahhhhh the one who pays ! For a second I thought he meant "users" ! :-)
100011_100001 5y ago
Reading the comments first I suspected this was an HN over-reaction to the list. However upon reading it myself I must totally agree. There is nothing actionable about this list. A lot of it is meant to sound wise, without any specifics. Definition of heuristics: > A heuristic, or a heuristic technique, is any approach to problem-solving that uses a practical method or various shortcuts in order to produce solutions that may not be optimal but are sufficient given a limited timeframe or deadline. A small sample of the heuristics from the "evolving list": > Our only measure of progress is delivering into our customers hands things they find valuable. > Outcomes matter more than output. A focus on output yields sub-par outcomes. None of this is practical or a shortcut of any kind. It just "sounds" nice as an abstract idea.
- yourenotsmart 5y ago
  > A lot of it is meant to sound wise, without any specifics. This unfortunately applies to most of the popular advice in our industry. You could argue that "meant to be wise, without any specifics" is a requirement for a meme to get picked up and recognized by a large enough mass of people in order for it to become viral. Consider if you can apply anything in SOLID in an actionable way. None of it is actionable, except LSP. It's meant to sound wise, without any specifics.
  - Verdex 5y ago
    I'm getting misty-eyed over here. Seriously, I thought I was the only one. I have heard almost no advice that's anywhere near actionable in our industry. The way I see it is that we have no objective ways to even talk about good code versus bad code (and forget all of the support tasks like "can we estimate this"; those require some objective understanding on how terrible the code happens to be). We've got code smells. Like, the most primitive and "from your gut" sense. This for-loop makes my tummy feel bad. It all feels like poetry to me.
    - Gupie 5y ago
      There are a number of agreed bad practises: long functions, deep nesting, obtuse identifiers, unrestricted use of gotos, global variables, no coding standard, premature optimisation, C macros, raw pointers...
oddthink 5y ago
Why do agile-folks seem to hate product managers so much? This comes out in #13, #19, and #20 (well depending on exactly what they mean by "managing".) I find it really helps to have someone dedicated to the product side, so they can help with prioritization, generating ideas for what to try next, keeping track of the research, and tracking the launch process and metrics. We could, I suppose, distribute all of that to the engineers, but there's value in that specialization. (I generalize to "agile-folks" here because I feel like I've seen this before, but I can't think of exactly where.)
- ItsMonkk 5y ago
  I'm not yet an expert on this, but I'm coming to the same intuition that the writer has so let me attempt to explain. Let's say we have 4 domains, and 4 domain experts. P is product, B is backend, F is frontend, and D is database(this is heavily simplifying, I know there are many sub-domains within each depending on the scope of the project). Each new feature starts with the P expert working with the team translating the user requirements into what he thinks is needed. B and F communicate with each other. B and D communicate with each other. But since none of them have a shared understanding, the communication is of poor quality. You get mistakes. You'll find that if you had an PF expert the implementation would be 10x simpler. You get things where if you had an PBFD expert would be 1 million times simpler. Without the cross-domain knowledge you will never know when those simplifying measure are possible. The problem with starting with a P is that the expert is basically starving the rest of the team of the knowledge that they have accumulated. They handle that work, it's up the the product expert to come up with the new features. And by putting that title on their head, and never letting the developers in, it tends to lock in place. You are only as creative as your feedback loops, and your feedback loops depend on the bandwidth of communication. Within waterfall that might be months. Within agile that is a sprint. But with a PBFD expert your feedback loops can be measured in seconds. You don't need PBFD experts, but it is very helpful to at least have translators. So there might be a PD expert, there might be a BF expert. That way you can get a reasonable translation of the requirement out. By taking on the team a Product Manager who is explicitly non-technical person, you lock that P in place. I think that's why we're seeing push-back to PM's where it's a general domain issue. P is a fine role, if you also have a PD, if you also have a PB, if you also have a PF. The Fullstack developer is already a BFD, why not also train them in the product? The example I like to give is that Linus Torvalds created git in 10 days because he was a master user of Source Control and knew exactly what he needed while also able to create everything, while Microsoft's Source Control team had worked with hundreds of developers over years and couldn't compete. When you have hundreds working on a project the ability to communicate in a depth-first-search style drops to 0, and you are left to only breadth-first-search solutions. Metcalfe's Law destroys productivity.
bottled_poe 5y ago
Got to around #8 and stopped reading. Too much absolutionist rubbish. Die-hard believers don’t produce the best results. How’s that for an absolute?
terrib1e 5y ago
Collectivism at its finest
charles_f 5y ago
> Outcomes matter more than output. A focus on output yields sub-par outcomes. In my experience, this is true mostly for planning and control. It's important to remember the goal when building something, but at some point you need to focus on the output as well. "a focus on outcomes only doesn't yield any output"
GnarfGnarf 5y ago
I see one thing missing: the value of the benefit we deliver, must be greater than the cost to develop it.
xupybd 5y ago
"Predictions are unreliable. Estimates are not promises" Ha, I wish that were the case. Everyone wants a date and gets upset when the deadline is missed.

121 points by dailymorn 5y ago

Sloppy thinking… new age bullshit… most of it collapses under mild scrutiny. Some of it is okay. I just don’t get, after decades and decades, how our industry continues to tolerate bullshit. Quality is not negotiable? Really? Negotiation is not collaboration? Really? This is not just wrong, it’s almost gaslighting.

jimktrains2 5y ago
I was going to pick a few to complain about, but there are just so many things on that list that are wrong or contradictory. Simple is a very relative thing, qnd not everything can be "simple". Not everything is a transient thing, especially if you're trying to improve ypur customers lives. Tinkering qith parts is often the only way to improve a system and setting your sights on changing everything at once is setting yourself up for being overwhelmed. It's just one overly-dogmatic, "new age bs" after another with little though to what the consequences of these heuristics would be.
bartread 5y ago
Agree. I was going to add cargo-cult, idealistic, and nonsense. I think reading this guy's list actually killed some brain cells. The problem is not just that we tolerate bullshit: we reward it. I'd bet he gets paid quite handsomely to trot out this bilge. Here's a thing close to my heart: "Knowledge work has unique concerns, unrelated to those of a factory or construction site." But notice how he doesn't talk about any specifics, or recognise that there are shades of difference in knowledge work: e.g., it's easier to make determinations about delivery when adding well-understood and tightly scoped CRUD pages, than it is when delivering a more R&D oriented outcome. Don't get me started on the Toyota nonsense though because we'll be here all day. Another bugbear: talking about outcome versus output without being specific about what you mean with these terms. Grr. And the first point about processes: they don't serve people, they serve business outcomes. Sometimes those things coincide; often they don't.
atoav 5y ago
> quality is not negotiable? Really? I read this as "certain principles must be upheld at any cost" and I agree with that. E.g. if your project is dealing with people's health data, not securing that database is a cut on quality you just shouldn't make. Or to phrase it the other way around: If your project cannot reach that basic quality level, maybe it should be ended right away, because it clearly lacks funding/resources. As a freelancer I wouldn't take that job. > Negotiation is not collaboration? Really? Well it can be, but it also can't be. The phrasing on this one is a bit vague. But if you read it as "just defending your interest and not trying to discuss common goals and the goals of the other side is not collaboration" it would be true again.
- adwn 5y ago
  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.
  - atoav 5y ago
    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)
    - adwn 5y ago
      > 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?
      - Verdex 5y ago
        Hard agree. A heuristic can only be said to work if it means the same thing to everyone. Like, if the list means anything to everyone, then how can we say that the list is responsible for success or failure? Otherwise what are we saying the causality is? Like, that the list is just somehow inspiring everyone to be successful? So, like, if we just believe enough in the list we'll get it done? No thanks. I'm not going to pray to some poetry.
omginternets 5y ago
You can really feel the thought leadership on this one, can’t you?
UK-Al05 5y ago
I mean you can have worse quality if you want. But won't have the effect you want. Aka speed. In fact the opposite is most likely to happen.

IshKebab 5y ago

Very woolly. I was expecting more concrete things like * Use static types * Use CI and version control * Use schema-based data storage * Prefer function calls to events * Use formal verification if possible etc.

Ygg2 5y ago
Interesting. Why function calls over events? And is it always applicable?
- adwn 5y ago
  I suspect because it makes both data and control flow more explicit and traceable. > And is it always applicable? No heuristic is always applicable.
  - naavis 5y ago
    > No heuristic is always applicable. Exactly. That's why it is called a heuristic and not a rule. :)
- IshKebab 5y ago
  Not always applicable but it makes debugging far easier, reduces the chance of events being lost and makes it easier and safer to understand and modify code.
axelroze 5y ago
> * 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".
- IshKebab 5y ago
  Schemas don't mean that formats can't evolve.

cheradenine_uk 5y ago

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 to actually, y'know, deliver? []1 https://www.kickstarter.com/projects/1086486319/agility-with-allen-the-whole-caboodle-video-class/posts https://www.kickstarter.com/projects/1086486319/agility-with...

Aeolun 5y ago
> Last Post: Module 1 released, more will follow shortly > November 2, 2017 Lol
- cheradenine_uk 5y ago
  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?
dgb23 5y ago
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/ https://holub.com/noaccountability/

seanhunter 5y ago

This list could have been generated by pointing GPT-3 at a list of self-help websites.

agge 5y ago

This resonates with my thinking as well. Although something I’ve always been missing from people talking about agile in general, is more specifics on how collaboration can happen. Especially collaboration with ”the customer” (customer is a terrible term). I’ve learnt so much more from reading blogs by Teresa Torres than from any agilist about how to actually learn from what you deliver.

eurasiantiger 5y ago

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

dgb23 5y ago
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.
yourenotsmart 5y ago
From the article: > You cannot change anything without changing everything. You cannot improve a system by tinkering with the parts. Those sentences seem to outright contradict each other...

tpoacher 5y ago

"Negotiation is not collaboration". That's about the only soundbyte I liked from this list; but, on the plus side, I did like that soundbyte quite a lot!

DanielBMarkham 5y ago

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 https://danielbmarkham.com

ycnews 5y ago
re:"weekly roundup"> F# Is The Best Coding Language Today Have you looked at http://nim-lang.org http://nim-lang.org ?

wiz21c 5y ago

> 12. We work to make our customer’s lives better and their work easier. We do that by providing a steady stream of artifacts and aid that they find valuable. This guy must be on another astral plane :-) Who is the customer ? Ahhhhh the one who pays ! For a second I thought he meant "users" ! :-)

100011_100001 5y ago

Reading the comments first I suspected this was an HN over-reaction to the list. However upon reading it myself I must totally agree. There is nothing actionable about this list. A lot of it is meant to sound wise, without any specifics. Definition of heuristics: > A heuristic, or a heuristic technique, is any approach to problem-solving that uses a practical method or various shortcuts in order to produce solutions that may not be optimal but are sufficient given a limited timeframe or deadline. A small sample of the heuristics from the "evolving list": > Our only measure of progress is delivering into our customers hands things they find valuable. > Outcomes matter more than output. A focus on output yields sub-par outcomes. None of this is practical or a shortcut of any kind. It just "sounds" nice as an abstract idea.

yourenotsmart 5y ago
> A lot of it is meant to sound wise, without any specifics. This unfortunately applies to most of the popular advice in our industry. You could argue that "meant to be wise, without any specifics" is a requirement for a meme to get picked up and recognized by a large enough mass of people in order for it to become viral. Consider if you can apply anything in SOLID in an actionable way. None of it is actionable, except LSP. It's meant to sound wise, without any specifics.
- Verdex 5y ago
  I'm getting misty-eyed over here. Seriously, I thought I was the only one. I have heard almost no advice that's anywhere near actionable in our industry. The way I see it is that we have no objective ways to even talk about good code versus bad code (and forget all of the support tasks like "can we estimate this"; those require some objective understanding on how terrible the code happens to be). We've got code smells. Like, the most primitive and "from your gut" sense. This for-loop makes my tummy feel bad. It all feels like poetry to me.
  - Gupie 5y ago
    There are a number of agreed bad practises: long functions, deep nesting, obtuse identifiers, unrestricted use of gotos, global variables, no coding standard, premature optimisation, C macros, raw pointers...

oddthink 5y ago

Why do agile-folks seem to hate product managers so much? This comes out in #13, #19, and #20 (well depending on exactly what they mean by "managing".) I find it really helps to have someone dedicated to the product side, so they can help with prioritization, generating ideas for what to try next, keeping track of the research, and tracking the launch process and metrics. We could, I suppose, distribute all of that to the engineers, but there's value in that specialization. (I generalize to "agile-folks" here because I feel like I've seen this before, but I can't think of exactly where.)

ItsMonkk 5y ago
I'm not yet an expert on this, but I'm coming to the same intuition that the writer has so let me attempt to explain. Let's say we have 4 domains, and 4 domain experts. P is product, B is backend, F is frontend, and D is database(this is heavily simplifying, I know there are many sub-domains within each depending on the scope of the project). Each new feature starts with the P expert working with the team translating the user requirements into what he thinks is needed. B and F communicate with each other. B and D communicate with each other. But since none of them have a shared understanding, the communication is of poor quality. You get mistakes. You'll find that if you had an PF expert the implementation would be 10x simpler. You get things where if you had an PBFD expert would be 1 million times simpler. Without the cross-domain knowledge you will never know when those simplifying measure are possible. The problem with starting with a P is that the expert is basically starving the rest of the team of the knowledge that they have accumulated. They handle that work, it's up the the product expert to come up with the new features. And by putting that title on their head, and never letting the developers in, it tends to lock in place. You are only as creative as your feedback loops, and your feedback loops depend on the bandwidth of communication. Within waterfall that might be months. Within agile that is a sprint. But with a PBFD expert your feedback loops can be measured in seconds. You don't need PBFD experts, but it is very helpful to at least have translators. So there might be a PD expert, there might be a BF expert. That way you can get a reasonable translation of the requirement out. By taking on the team a Product Manager who is explicitly non-technical person, you lock that P in place. I think that's why we're seeing push-back to PM's where it's a general domain issue. P is a fine role, if you also have a PD, if you also have a PB, if you also have a PF. The Fullstack developer is already a BFD, why not also train them in the product? The example I like to give is that Linus Torvalds created git in 10 days because he was a master user of Source Control and knew exactly what he needed while also able to create everything, while Microsoft's Source Control team had worked with hundreds of developers over years and couldn't compete. When you have hundreds working on a project the ability to communicate in a depth-first-search style drops to 0, and you are left to only breadth-first-search solutions. Metcalfe's Law destroys productivity.

bottled_poe 5y ago

Got to around #8 and stopped reading. Too much absolutionist rubbish. Die-hard believers don’t produce the best results. How’s that for an absolute?

terrib1e 5y ago

Collectivism at its finest

charles_f 5y ago

> Outcomes matter more than output. A focus on output yields sub-par outcomes. In my experience, this is true mostly for planning and control. It's important to remember the goal when building something, but at some point you need to focus on the output as well. "a focus on outcomes only doesn't yield any output"

GnarfGnarf 5y ago

I see one thing missing: the value of the benefit we deliver, must be greater than the cost to develop it.

xupybd 5y ago

"Predictions are unreliable. Estimates are not promises" Ha, I wish that were the case. Everyone wants a date and gets upset when the deadline is missed.